构建Disk镜像的进阶配置

我想指定构建的发行版的版本和镜像站！

虽然对Arch用户可能没有意义，但是你可以通过[Distribution]段内的Release=配置项来指定使用的版本号：

1
2
3

[Distribution]
Distribution=debian
Release=forky

而对于Arch这类滚动发行版，你也可以使用Snapshot=配置项来指定使用某一天的快照来构建高度可复现的镜像：

1
2
3

[Distribution]
Distribution=arch
Snapshot=20250927

守护进程不是服务

守护进程不是服务，或者说，守护进程不完全是服务，服务意味着一个主进程，和能够通过某种方式与该主进程进行交流与控制的另一个进程；而守护进程仅仅意味着服务的主进程部分。

构建第一个镜像

MKOSI官方提供了一系列内置的镜像模板，如果你只是急于求成，那么不必太过担忧，你只需要这样：

1
2
3
4

mkosi --format=directory \
    --include=mkosi-vm \
    --distribution=arch \
    build

• --format=directory：产品格式为目录。
• --include=mkosi-vm：使用内置的mkosi-vm模板。
• --distribution=arch：构建一个Arch Linux镜像。

这是一系列MKOSI镜像构建器由浅入深的新手教程文本，我们会以一个客制化的Arch Linux发行版为例子，详细讲解MKOSI的使用方法。让我们开始构建镜像吧！

通过systemd 257以后提供的systemd-import-generator组件，我们现在终于可以完全依赖UEFI HTTP Boot协议实现完整的新时代网络启动了。

译自：Deciphering Glyph: Thank You Lennart

Upstart是Canonical开发的，事件驱动的init系统。

Upstart是为了解决SysV init系统的一些固有问题而诞生的，在Upstart的开发者看来，SysV init至少有以下问题：

1. 面向服务器场景设计，建立在硬件不变的基础上。
2. （在当时）不支持并行，性能低下。
3. Init脚本的资源开销较大。

而这些问题源于其根本上的限制：

……（SysV init）没有意识到现代Linux的动态性本质，针对每一个可能的硬件Event，如果希望进行处理，那么就必须要有一个独立的守护进程对其进行轮询监听。

因此，Upstart的想法是：

在条件满足时，启动服务。服务（也就是Job）本身只需要描述它在启动时需要的条件，以及在启动时执行的程序。

本文是我在制作自己的USR不可变系统时的一些记录。你可以访问MoltenArmor/not-so-immutable-os查看我的系统源码。

把时间往回拨到20世纪末，1983年，AT&T公司发行出了第一个成功的商业版UNIX，即System V Unix。该系统在各方面都给人留下了深刻的印象，init系统方面也不例外。