1. 从标题说起

新井圭一（あらゐけいいち）老师对作品的命名一直抱着非常头疼的态度：

给自己的作品命名这件事本身是否妥当？这不是会极大束缚接受者的感受力吗？（自分の作品に題をつけるのもどうか？と思った。それは、受け手側の感受性をかなり縛ってしまうのではないか？）

他的顾虑其实很容易理解：一部作品本来携带着无限饱满、且不断外延的意义，但一旦你为它取了一个极其有限的名字，那么它溢出命名之外的那部分东西就被杀死了。打个比方：一幅画如果被命名为《手机》，读者一定会带着”手机在哪”的好奇去阅读——即使手机从来不在画中出现，也不是画的中心——“手机”这个词作为一种不在场的存在，已经悄悄统摄了整部作品的意义走向。命名就是这样一种暴力：它选中一个词，用这个词杀掉了其余一切可能性。

构建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查看我的系统源码。