Upstart是Canonical开发的，事件驱动的init系统。
Upstart是为了解决SysV init系统的一些固有问题而诞生的，在Upstart的开发者看来，SysV init至少有以下问题：
而这些问题源于其根本上的限制：
……（SysV init）没有意识到现代Linux的动态性本质，针对每一个可能的硬件Event，如果希望进行处理，那么就必须要有一个独立的守护进程对其进行轮询监听。
因此，Upstart的想法是：
在条件满足时，启动服务。服务（也就是Job）本身只需要描述它在启动时需要的条件，以及在启动时执行的程序。
本文是我在制作自己的USR不可变系统时的一些记录。你可以访问MoltenArmor/not-so-immutable-os查看我的系统源码。
ParticleOS是完全使用systemd的不可变基础设施构建起来的不可变元Linux发行版，它可以基于各种Linux发行版进行构建：ParticleOS。
译自：darknedgy.net。
1 | 我并不确定自己是否真的热衷于重新实现NetworkManager…… |
—— Lennart Poettering，2011年3月
十年前，systemd 首次出现在世人面前，迅速成为近代历史上最持久、最具争议性和两极分化的软件之一，尤其是在 GNU/Linux 世界中。然而，自 2012 年至 2014 年的大规模社区论战以来，围绕 systemd 的辩论并未在质量上有任何提升。尽管 systemd 受到了广泛关注，但从技术和社会层面来看，人们对它的理解和研究仍然严重匮乏。
我撰写这篇文章，既是为自己寻求一份慰藉——让我能够彻底放下对它的纠结，也是希望我的分析能为这场长达十年的闹剧提供一些新的思考，而不至于让它如 Benno Rice 著名的描述那样，“不过是一场悲剧罢了”。
在第一章中，我将基于当时的邮件列表，探讨在 systemd 出现之前，为现代化 init 程序、rc 脚本和服务管理方法所做的努力，以及那些推动变革的主要动机。我会从不同类型的 Linux 用户之间的文化分歧开始谈起。
第二章中，我将讨论 systemd 的早期历史和设计哲学，以及促使其被广泛采用的因素。
第三章将对 systemd 进行技术层面的批评。我假设读者已经熟悉 systemd，并将重点放在其实现细节上。我还会包含一些基于 Bug 报告的“案例研究”，以更深入地阐释一些较为枯燥的理论。
第四章将探讨在自由开源软件（FOSS）开发中与 systemd 类似的其他历史事件，综合第一章和第二章中的一些主题，并对 Linux 低层用户空间（Low-level Userspace）的未来前景提出一些猜想。
mkosi-initrd是使用MKOSI进行Initrd构建的工具。
1 | mkosi-initrd [选项] |
可用选项有：
-k|--kernel-version=：使用的内核版本，默认使用$(uname -r)。-t|--format=：输出格式，可选值有cpio或uki，默认使用cpio。-g|--generic：生成通用Initrd，即可以在不同的硬件平台上启动当前系统的Initrd。-o|--output=：输出文件名前缀，默认为initrd。-O|--output-dir=：输出的目录，默认为工作目录。--profile：启用的额外Initrd配置，默认不启用。lvm：LVM支持。--debug：Debug输出。--debug-sandbox：使用strace运行mkosi-sandbox。译自：https://jdebp.uk/FGA/unix-daemon-design-mistakes-to-avoid.html
对于Unix上的守护进程，有一些传统概念带来的谬误，这些谬误已经严重影响了现代进程监视器程序（Daemontools家族、systemd）的正常运作，因此必须予以避免和修正。