Debian 技术委员会推翻 systemd 变更
Debian软件打包人员在配置所打包软件时拥有很大自由度；例如，他们可选择禁用默认功能，若认为这些功能存在安全隐患。但打包人员必须确保其软件包符合Debian政策，无论上游开发者的偏好如何。若打包者未能遵守政策，Debian技术委员会 (TC)可介入干预，例如近期针对systemd变更的干预——该变更破坏了多个依赖于全局可写/run/lock目录的程序。
文件系统层次结构标准(FHS)规定，/var/lock目录应用于存储设备及其他多应用共享资源的锁定文件。在Debian系统中，/var/lock是指向/run/lock的符号链接。/run目录由systemd-tmpfiles在系统启动时创建，作为专用于运行时文件的tmpfs文件系统。
尽管文件系统规范（FHS）已停更逾十年，Debian政策仍沿用其标准。该规范在FHS 3.0发布后并非完善而是被搁置——尽管存在缓慢推进的复兴计划，试图以FHS 4.0版本修订标准，但至今未见成果。与此同时，在缺乏现行标准的情况下，systemd已将其文件层次结构文档作为规范独立出来，移交至Linux用户空间API（UAPI）组。LWN于八月报道了这一进展，该事件与Fedora寻找FHS继任标准的探索密切相关。。
锁定 /run/lock 目录
在Systemd v258中，/run/lock目录已被废弃。但项目组并未完全移除该目录，而是将默认权限调整为仅允许root写入——这比Debian此前默认的“世界可写”权限更为严格。计划在v259版本中彻底移除/run/lock目录，但用户(或发行版)仍可通过在/etc/tmpfiles.d添加配置文件覆盖systemd默认设置，以保留旧版行为并创建具有所需权限的目录。
Debian项目于八月发布了新稳定版Debian 13(代号“trixie”)，并已启动Debian 14(代号“forky”)的开发工作。当前稳定版搭载systemd v257，因此稳定版用户不受此变更影响。但v258已进入Debian不稳定分支，其中对/run/lock目录的变更导致其他软件出现故障，例如Unix-to-Unix Copy程序(UUCP)和cu实用工具。该目录的使用不仅限于经典工具；Zbigniew Jędrzejewski-Szmek 反对 在v259版本中移除/var/lock目录，认为此举将破坏alsa-utils的正常运行，并给发行版带来额外工作：
此举只会给发行版制造陷阱：若他们察觉变更，便会创建本地覆盖方案，最终导致系统复杂度增加却毫无益处。若他们未能察觉，系统将长期失效直至用户反馈问题，届时他们才会添加覆盖方案。
8月13日，系统d软件包维护者Marco d’Itri针对uucp软件包提交了错误报告，指出systemd v258-rc1-1版本破坏了uucico功能，同时针对systemd软件包提交了另一份错误报告，其中援引了/var/lock目录的FHS规范条目。他提出折中方案：可将目录权限改为仅限dialout组写入，而非开放写入权限。他还提及2014年曾尝试将使用UUCP式锁的软件现代化改造为采用flock()机制，但该计划最终搁浅。
“已废弃且严重过时”
系统维护者卢卡·博卡西(Luca Boccassi)指出，相较于临时恢复旧行为，/run目录下存在可供全球写入的目录反而构成安全风险。任何进程都可向/run目录无限写入数据， 这将通过耗尽空间或inode实现系统拒绝服务攻击；一旦/run被填满，关键服务如udev将停止运行。他宣称FHS规范“已死且严重过时”。
该问题已在systemd项目中讨论过； Lennart Poettering曾回应称在“现代环境中”看不出/var/lock的意义，但各发行版可自由决定：
这更像是上游 systemd 向下游传递的接力棒：若发行版需要此类传统接口，只需通过发行版专属的 tmpfiles 替换方案添加即可。但强迫那些具有前瞻视野的用户继续保留该目录确实毫无意义。
Poettering认为发行版可自主抉择，尽管想到允许非特权程序填满目录就令他毛骨悚然。Boccassi对此表示赞同 在回应Debian systemd漏洞时表达了相同观点。任何软件包都可以提供tmpfiles.d配置来创建目录并承担管理责任：
我当然不会阻止任何人尝试这样做，但同样也不希望这些旧的临时解决方案出现在本软件包中。
距离Forky发布还有约两年时间，这应该足够在其他地方添加此临时方案，或修复剩余程序以使用BSD锁，或两者兼顾。因此我不会因这个小众案例而阻碍新版本进入测试阶段，抱歉。
Boccassi已用“WONTFIX”标签关闭该漏洞报告。
Debian政策
9月1日，d’Itri回应称上游systemd的意见在此事中无关紧要。Debian政策要求为串行设备锁定文件保留目录，但他同时开启了一个错误报告重新审视该政策——毕竟使用/var/lock存储串行设备锁定文件的实践可追溯至1980年代。然而/var/lock由systemd提供，因此他认为除非确定其他软件包应承担创建该目录的责任，否则这属于systemd的缺陷。“但你不能简单地认定政策违规不存在。”
Thorsten Alteholz 于9月15日向Debian技术委员会提交了漏洞报告，因systemd漏洞已被标记为WONTFIX，他寻求后续处理建议。
那么您建议如何推进？修改Debian政策(如#1111839所提议)、撤销systemd的变更、寻找Debian全局解决方案，还是让每个软件包维护者自行实现解决方案？
Bdale Garbee也对此漏洞发表了看法。他表示自己“几乎时刻依赖cu命令与笔记本电脑通过USB连接的嵌入式串行控制台交互”。他对systemd“毫无预警”的变更感到沮丧，并期待技术委员会的回应。
9月24日，Matthew Vernon就该漏洞作出回应，并抄送给systemd维护者联名邮箱。他表示Debian政策似乎要求遵循FHS规范，“至少在我们制定过渡计划前如此”，并询问systemd是否愿意撤销该变更。systemd维护者均未作出回应。
覆盖处理
Vernon 于9月29日更新该漏洞报告，称技术委员会(TC)在最近会议上讨论了此事。结论是systemd应遵守政策，即遵循FHS规范。他提交了技术委员会将投票表决的草案文本，其中指出委员会“理解”flock()是更优解决方案的论点，但强调“Debian开发者的重要职责之一是确保Debian软件符合Debian政策”。最终投票文本于10月2日提交委员会审议。
该投票包含三项方案，均要求systemd软件包为/var/lock目录提供“足够宽松的权限，使现有Debian软件能继续使用该目录实现串行设备全局锁定(及类似用途)”。委员会将依据《Debian宪章》行使权力，强制覆盖systemd维护者的决策。选项如下：
- systemd的此项变更须持续生效，直至受影响软件完成满意迁移且政策相应更新。
- systemd的此项变更须持续生效，直至政策更新允许例外情况。
- systemd的此项变更须持续生效，直至技术委员会(TC)允许例外，而TC预计将在达成合适过渡方案后予以批准。
Vernon 于 10 月 6 日回复称决策已达成，方案一获胜。
解锁机制
Debian持续采用UUCP式锁定机制确实显得相当过时。FHS 3.0标准显然已接近其有效期终点，即便尚未正式失效。
相比之下，Fedora的uucp软件包已通过补丁改用 lockdev替代。即将发布的Fedora 43将采用systemd v258版本，而/run/lock目录不再具备全局写入权限。Debian或许可借鉴Fedora对uucp包的处理方案，但这无法解决其他受/run/lock变更影响的Debian包问题。当然还需考虑第三方软件的影响。
截至目前，Boccassi尚未回应讨论；我曾邮件询问d’Itri为何不亲自修改(既然他知晓该漏洞)，他于10月13日回复称“维护者不能强迫其他维护者做出决定”。由于他和Boccassi对修改存在分歧，最终交由技术委员会裁决。他表示计划在本周内准备合并请求以落实技术委员会的决定，“正如我已与Luca达成共识的那样”。
本文文字及图片出自 Debian Technical Committee overrides systemd change
这部分内容似乎带有明显编辑性质：
>尽管文件系统标准(FHS)已停更逾十年，Debian政策仍引用该标准。
文件系统标准需要何种持续维护？此类成功的标准本应保持静态，除非存在亟待解决的重大问题。标准的初衷正是为避免频繁变更。
>FHS 3.0发布后，该规范并非真正完成，而是被搁置…
明白了。
>…尽管存在缓慢推进的复活计划，试图修订为FHS 4.0标准，但至今未见成果。
那么它并未被彻底放弃。缓慢推进的流程恰恰是文件系统标准维护所需的特质。
>与此同时，在缺乏现行标准的情况下，systemd已将其文件层次结构文档作为规范移交至Linux用户空间API(UAPI)组。LWN在八月报道了这一进展，该举措与Fedora寻找FHS继任者的计划相关。
啊。Systemd/Fedora想要一个能直接掌控、不受他人干涉的标准。
作者注：该标准已被废弃。我曾引用前维护者的声明佐证此事。当前的更新工作由少数人员发起，他们请求自由软件基金会接管，但在初期热潮后(迄今)进展甚微。这点也体现在我近期撰写的另篇关于FHS的文章中。
在当前更新团队介入前，该标准已近十年无人问津。这并非进展缓慢——而是彻底被弃置。
FHS的归属权最终在于用户群体，而非维护者。我年岁尚长，仍记得FHS影响出现前的混乱景象。它的价值在于某种程度上的公信力，而非某处文件宣称其为标准。若需变更，请通过政治运作争取支持。不能单方面宣布新标准后便为所欲为。
开发者常将标准视为技术规范。实则它本质是政治意志的宣言。所谓因缺乏“维护”而“废弃”标准的说法，恰恰体现了将标准视为规格书具体化产物——即实际程序的思维误区。
虽有本质区别，但试想若因法律十年未更新就认定其失效，岂非荒谬？
我同意——在法律约束和十年更新周期的前提下。但那些150年未更新的法律呢？我们日常忽视的这类法律比比皆是。
软件的更新周期又该如何界定？
> 那150年未更新的法律呢？我们日常忽视的这类法律多的是。
细节或许有微调，但核心法律大多更古老。谋杀、盗窃等罪行本质不会改变。
即便是那些荒谬混乱的法律也寿命悠长。例如“永续禁止规则”
> 即便那些荒谬混乱的法律也历久不衰。例如“永续禁止规则”
这倒不是我心目中荒谬法律的典型代表。该规则旨在防止财产控制权永久留存于已故全权所有者的遗嘱中，规定遗嘱效力终止后，完整所有权应归属于在世者。
美英法律体系很大程度上基于几百年前的普通法规则。有些古老法律已被编纂成法典，有些则未被编纂，但无论哪种情况，都无需因其年代久远就废弃它们。相反，那些历经岁月洗礼仍无需修改的法律，恰恰证明了它们是极其优秀的法律理念。
我不确定英国是否算好例子。那里存在大量怪诞而晦涩的法律，如今根本无人执行或遵守——从关于可疑三文鱼处理的法规，到规定谁能驱赶绵羊穿越塔桥的种种条例。
这些法律得以存续，并非因其被视为良策，纯粹是因为忽视它们引发的问题，远小于废除它们所需付出的努力。
我们还有许多法律虽仍被遵守，但仅限于最严格的字面意义。所有“议会路线”列车时刻表都属于此类。这些列车服务要求每日至少运行一班，有时每周仅一班，实际无人使用，甚至有些列车只停靠没有实际公共入口的车站。这些法律得以保留并非因其合理性，而是维持列车运行比争取议会时间废除法律更为便捷。
法律不会因未更新或未审议而自动失效；请谨记，我们仍在 适用《联邦卫生法》，即便未更新，该法仍处于有效实施状态。
法律效力持续至其被正式：
* 由相关立法机构(议会、国会等)废止(撤销)；
* 被法院裁定违宪或无效。
设置150年“删除”时限将真正动摇法律体系根基。律师、法官及企业均依赖核心法律(如合同法、物权法、税法)的延续性。若某部150年前的物权法突然失效，可能瞬间使数百万土地产权与商业合同归于无效…
> 法律效力持续至被正式：* 法院裁定违宪或无效。
错误。法律 依然 有效——只是 无法强制执行。美国当前正体会到关键差异：只要法律仍存于法典，最高法院裁决即可使其瞬间恢复可执行性——即便违背民众意愿。
正确做法应是“清理”不可执行的法律，但政客们(可以理解地)不愿为此耗费政治资本，毕竟此事毫无实际回报。
另有其他原因。负责执行特定法律的机构可选择不予执行，致使法律形同虚设。或因技术社会变革使法律过时——例如原法律规范的事态已不复存在。法律也可能为处理仅发生一次的特定事件而制定。一旦事件结束，该法律便形同虚设。无需正式废除，因其已失去适用性。
此外，法律通常会定期修订以适应社会新发展、澄清措辞含义，或与其他法律及观念转变保持协调。一部150年未曾修订的法律，很可能已因上述原因沦为过时法规。
当然，这些讨论已略偏离主题，但关键在于法律确实可能因人为或偶然因素而过时失效。反之亦然：人们日常接触的大多数法律都持续更新，以确保其仍能反映适用社会的现实需求与社会意愿。
同样存在许多150年前的法律，我们并未将其废弃。
“不可杀人”这条诫命需要多久更新一次？
连自卫、保护家人或他人都不行？红帽上可有不少人歌颂杀害当时无辜者的行为。
显然本意是“不可谋杀任何人”……其他解释既不合逻辑，也与圣经其他内容相悖。
“谋杀”的定义是“非法杀戮”，你将其简化为“非法杀戮违反法律”——这根本毫无意义。
这种解读方式有误。《圣经》从未将其他法律作为权威来源。所谓谋杀只是“非法杀戮”的表述才是真正空洞的论断。显然《圣经》允许人们战斗和自卫。谋杀通常指出于恶意(或毫无理由)蓄意且不必要地杀害他人。恶意动机通常包括怨恨、贪婪或图谋私利。
>《圣经》并未援引其他法律作为权威来源
《圣经》本身就是法律的来源。我的观点是：仅凭你所谓的“显而易见”方式解读是行不通的——“不可杀人”这条诫命必须辅以其他规则才能明确“谋杀”与“合法杀戮”的界定标准，而圣经中恰恰包含大量此类规定。
> 谋杀通常指出于恶意(或毫无理由)蓄意且不必要地杀害他人。恶意动机通常表现为怨恨、贪婪或图谋私利。
这是你个人的解读方式。现代法律允许出于贪婪的杀戮——当开枪的士兵与觊觎资源的政治家身份不同时；我们允许国家以报复性打击实施怨恨杀戮；我们允许警察在自卫时开枪——即便理论上存在其他制服手段却因不便而放弃。另一方面，我们不再允许用石头砸死违反安息日的人。
显然，区分谋杀与合法杀戮的标准清单非同小可，且这份清单具有可变性。实践中这些标准被编纂为法律，这意味着谋杀即“法律未予许可的杀戮”——这正是我试图阐明的核心观点。
回到最初的讨论：与ikiris最初的论断相反，经文并非“不可 杀人”而是“不可 谋杀”。过去几千年间，我们对“谋杀”的定义(以及由此延伸的“不可谋杀”的含义)进行了大量更新，因此宣称 “不可杀人”永远无需更新"的论断实属谬误。
古希伯来语中“杀戮”与“谋杀”本无对应词汇，故你们整场讨论皆基于翻译选择。
对熟悉圣经的人来说这很明显哈哈。它或许存在诸多矛盾，但这并非其中之一。古人对谋杀的理解具有特定内涵，这种理解至今仍适用于我们。
>这是你的解读方式。现代法律允许出于贪婪的杀戮——只要扣动扳机的士兵与觊觎资源的政客身份不同。
如我所言，我并非指任何国家的法律。现代国家的法律与圣经解读无关，词典释义同样不具参考价值。
>回归最初讨论： 与ikiris最初的主张相反，经文并非“不可杀人”而是“不可谋杀”。过去几千年间，我们对“谋杀”的定义(以及“不可谋杀”的内涵)进行了大量更新，因此宣称“不可杀人”永远无需修订是错误的。
唯一需要更新的是译文。其本意清晰而普世：除自卫外不得杀戮。无论数千年前还是今天，这都同样违背社会准则。
除非上帝吩咐你。
"现在你去攻击亚玛力人，将他们的一切尽行毁灭[a]。不可怜悯，要将男女、孩童、婴儿，并牛羊、骆驼、驴子尽行杀死。"
“耶和华你的神将他们交在你手里，你击败他们之后，就当将他们尽行灭绝。[a] 不可与他们立约，也不可怜恤他们。”
等等
哈哈没错…我听过一些另类解释。十诫在基督教之外并不被认可。它们只是犹太人典籍中若干重要且听起来普遍的规则——犹太人时常与外族交战。同一本书里许多规则都规定了用石头砸死的刑罚。显然，杀戮至少在惩罚和战争中是被允许的。常识也告诉我们，没有任何宗教能真正禁止自卫行为。
天啊。亚玛力人到底做了什么？
不用查资料就知道，那些经典理由几乎总是掩盖他们想要掠夺我们财物的借口。
并非如此：《撒母耳记上》第15章开篇写道：
"撒母耳对扫罗说：'我奉耶和华之命膏你作以色列王，现在你要听耶和华的话。2 万军之耶和华如此说：因亚玛力人从前在埃及路上伏击以色列人，我必惩罚他们。3 现在你要去攻击亚玛力人，将他们一切所有的尽行毁灭[a]，不可怜惜他们，要将男女、孩童、吃奶的，并牛羊、骆驼、驴尽行杀死。'"
后来经文提到耶和华对结果不满，因为他们没有杀尽牲畜和人民… 当然这是神话作品，但其信息显然并非鼓励以色列人去掠夺这些民族。
“显然意图是”恐怕与150年前的“显然如此”已不尽相同！
在上下文中依然显而易见。这又不是食谱或路标哈哈…
美国宪法历经236年依然有效，更古老的法律仍在执行。美国法院有时会援引殖民地成立前英国的判例。
与此同时，某些颁布数月的法律却被执法者忽视，因为没人强制要求他们研读。正是这种效应导致众多旧法被默许废止而非正式废除。当无人骑马时，谁还会在意进店时如何拴马之类的规定？
> 美国宪法历经236年依然有效
确实如此，但近些年宪法修订的频率远高于此。
当然，最后一次修订距今远不止十年之久。宪法最近一次获得批准的修正案——第二十七条修正案(1992年批准)——令人难以置信的是，它早在1789年就与我们熟知的《权利法案》十条修正案以及另一条未获批准的修正案一同提出。在迄今通过的二十七条修正案中，国会最近一次提出的第二十六条修正案，其提案与批准均发生在1971年。
您是否暗示1992年在宪法中增补条款：任何改变参议员及众议员薪酬标准的法律，须待众议员选举后方能生效
竟会对其他条款产生影响？按此逻辑，任何法律的修订都会自动更新所有未被修改的既有法律。或者是我完全误解了您的观点。
我的观点是：当一部文件历经数十次修订直至数十年前才终止更新时，仅强调其数百年历史的原始版本实属误导。(且包括1971年在内的许多修订，其影响远超你引用的第二十七条修正案。)
宪法整体陈旧僵化亟需全面修订固然属实，但讨论焦点在于：当长期未更新的旧法被忽视或强制执行时该如何处理。
宪法确属单一法律而非多部独立法规，其修订频率远高于最初颁布或批准的年代。且该法至今仍主要被执行(例外情况虽在增加，但这完全是另一场讨论)。
> 经数十次修订
实际为18次。共计27条修正案，其中第1至10条均于1791年12月15日通过。
> 数十年前的事
过去54年间未曾有过实质性变更。
> 宪法确属单一法律而非多部法律
这些近期修正案至少构成不同法律。若坚持称其为单一法律，则美国存在两种联邦法律体系：一种需经各州批准，另一种则无需。
> 不，共18次。总计27项修正案，其中第1-10条均于1791年12月15日通过。
修正合理。
> 这些近期修正案至少构成不同法律。
仅在“任何新颁布的法律即为新法”的意义上成立，但依此标准，任何法律都无法在更新后保持其原有法律身份。这种定义对讨论旧法是否被更新毫无意义，因为按此标准任何法律都无法被更新。
律师和法官并不完全采用这种定义，正如程序员不会认为软件补丁改变了被修补程序的基本身份(除版本号等标识外)。
他们在指代国会单次立法时确实采用该定义，正如程序员既会指代补丁及补丁版本，也会指代跨越多个补丁(版本)长期存在的程序本体。具体采用何种定义取决于语境，而实际所指则由语境与具体措辞共同决定。
> 若坚持称其为单一法律，则美国存在两部联邦法律。
美国联邦法律远超两部，但单次立法通过的法律数量通常少于一部——除非采用“联邦法律”特指单次立法通过的含义。
例如，多数联邦税法明确修订《1986年国内税收法典》，该法典至今仍是联邦税法的正式名称。同理，多数移民法修订《1954年移民与国籍法》(年份可能有误)，即便距今已逾七十载。期间颁布的众多“修补性”法律虽通过公共法律编号及名称拥有独立身份，但它们仅更新特定可识别的基础法律，并未取代原法。
其他联邦法律(如多数年度拨款和授权法案)则独立存在，通常不作定期更新，但具有有限的效力期限。常见条款常从上一版本延续至下一版本，但每次修订时均需重新立法。
而在联邦法律体系的诸多领域，《美国法典》才是具有官方权威性的版本，而非像税法和移民法那样仅作为便利版本存在。对《美国法典》直接权威部分的修订会明确修改《美国法典》本身，而非单独命名的法律，因此《美国法典》的直接权威部分(无论是单独还是整体)在我讨论的意义上构成单一联邦法律。
诚然，无论在法律领域还是软件世界，这类问题都复杂而混乱。
> 一类需要各州批准，另一类则无需如此。
是的，宪法修正案(从某种意义上说)是法律，它们修正另一种意义上的法律，且需要各州批准；而国会常规法案(从第一种意义上说)是法律，它们可能修正也可能不修正一种或多种现存法律(从第二种意义上说)，且无需各州批准。
> 是的，宪法修正案是法律(从某种意义上说)，用于修订法律(从另一种意义上说)，需要各州批准；而国会常规法案是法律(从第一种意义上说)，可能修订也可能不修订一项或多项现行法律(从第二种意义上说)，无需各州批准。
没错，显然我们认同现状，这只是无关紧要的定义问题。
> 但这种定义对讨论旧法是否更新毫无助益，因为按此定义任何法律都无法更新。
基于现有组织架构处理法律事务显然更便捷——税法与家庭法等相互独立。赞，国会正以合理效率运作。
然而时效性至关重要：宪法明确禁止追溯性立法。此外，当新旧法律冲突时，即使未明确废止旧法，新法仍具效力。因此每项法案都是实质不同的法律，冲突解决后任何时刻都仅存在一部有效法律。
最终形成三种相互矛盾却仍具实用价值的定义。但依我之见，组织结构定义在法律层面意义最淡薄，实务层面却最实用。
你是说像那些禁止在主干道上倒着牵牛行走的本地法规？或是规定机动车前方必须配备提灯人的法律？
没错，但标准本身并非法律。
法律可以强制要求采用特定标准，但标准本身不具备法律效力。
正因如此，打破标准往往是成功之道。愚蠢的例子：苹果及其所有专有非标准技术。
> FHS最终归属于用户群体，而非维护者。
我完全认同标准无需频繁更新也能保持相关性，但生态系统必须持续遵循标准——问题在于Linux用户正日益偏离FHS规范。
FHS未能准确描述实际应用场景，既无更新计划以反映现状，也无生态系统升级方案来精准实现FHS规范。
无论你是否认同：FHS已名存实亡，且无人有意重振它。
咦，大多数程序不都遵循它吗？不遵循就是bug？
我仍认为你未能充分说明这为何重要。重申楼主的问题：它需要哪些长期缺失的更新？毕竟“将X内容放置于Y位置”这类文档本就不该需要维护。
FHS 3.0 未能反映当前实践，例如 /usr 合并方案和 /sys 目录。过去十年间，该规范在其他方面也存在被废弃或遗漏的发展。
>> 尽管文件系统标准已停更逾十年，Debian政策仍引用其规范。
> 文件系统标准需要持续维护吗？此类成功的标准本就应保持静态，除非存在重大问题需解决。定期变更恰恰是标准最初要规避的现象。
2025年的今天，任何想被视为现代的事物(而所有事物都应如此)，都需要持续变革并定期推出“改进”。
>>…尽管存在缓慢推进的FHS 4.0复兴修订计划，但尚未取得任何成果。
> 看来并未被废弃。缓慢推进恰恰是维护文件系统标准所需的节奏。
FHS团队该行动起来了。在人工智能助手如此成熟的今天，这种缓慢进度毫无借口可言。他们至少应实现季度更新，并每隔一两年推出重大变更。几十年来都显而易见：“etc”亟需更名为“config”，“home”改为“user”，“usr”则应改为“Program Files”，才能跟上现代用户体验趋势。
我实在分辨不出这是否是讽刺。
看到结尾的“Program Files”就该明白了吧 🙂
总之Linux社区整体开发流程过于陈旧，亟需现代化改造，向行业领军者(如MS Teams)学习最佳实践。
Linux理应采用谷歌式开发模式，以网络规模为视角。移除uucp、tar、yacc、roff等组件(当然要提前30天通知！)，将所有“creat”用法修改为添加末尾“e”等。
而systemd早已遵循微软最佳实践，例如“火与动”https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
X11团队如此努力。我对Wayland的演进充满好奇，但GTK和QT的历史让我不太乐观。
等等你是在开玩笑吧？我已经搭建好Kubernetes集群，能通过全球负载均衡的CI/CD管道为FHS供能，还有智能LLM持续优化系统——我们正全力冲刺，让你永远搞不清文件藏哪儿！
这就像文件版的ASLR，但不需要地图——因为开拓者不需要地图，他们才是造图者！这可是尖端技术，绝对是增值服务！
(注：此处为强制性/s标记)
好吧，这只有一半是讽刺，还是说这条回复本身也是讽刺？我是说，微软Teams？认真的吗？
(是的，这条回复同样是讽刺)
反驳观点：现代发行版的需求在某些方面已超越FHS规范，且各发行版虽存在细微差异却相互不兼容。
若标准无法反映现实，便毫无价值。我认为努力使其回归实际应用场景是值得的。
NixOS阵营笑出声
NixOS能如此流畅运行实属奇迹，尽管它彻底打破了FHS规范——不仅是表面上的改动(比如不使用/bin目录)，更包括放弃动态链接(故采用/var/lib和/usr/lib目录)、将手册页资源与配置文件打包到二进制文件的同一派生中，甚至偶尔篡改二进制文件重写路径。
另一方面，传统发行版也有其存在的价值。
在systemd偏离标准的背景下，这种观点很有意思——现实使用场景与systemd变更的冲突正是导致 bug 的根源。
/usr 合并正是现代 FHS 可能体现的范例。
OS X并未合并/usr目录。在我的Mac上，/bin是独立目录而非指向/usr的符号链接。Linux是否存在OS X所缺乏的充分理由？
独立/usr目录的初衷早已过时。现代存储技术不再限制我们必须挂载远程分区来存放启动系统所需的大量二进制文件及其他组件。
我猜你指的是将启动关键二进制文件划分到
/bin目录的做法，但“独立/usr目录的初衷”比这更古老也更糟糕。在原始Unix系统中，/usr本是用于存储用户主目录[1]的，1971年因单张1.5MB RK05磁盘容量不足，才被操作系统征用。此后无人梳理这个变更，我们至今仍在忍受这个权宜之计。[1] https://lists.busybox.net/pipermail/busybox/2010-December/07…
换言之，支持usrmerge的最有力论据就是缺乏反对它的有力论据？
我认为当前最强的反对理由在于：当/usr位于独立分区时systemd会报错[1]，且其开发者已就此问题发表过意见[2]。
[1] https://freedesktop.org/wiki/Software/systemd/separate-usr-i…
[2] https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor…
sysvinit 完全能接受在网络可用时立即挂载 /usr 的指令，若你设置了在 /usr 可用前运行的初始化脚本，而该脚本又依赖 /usr，那便是你自身的问题。
systemd 依赖 /usr 目录的可用性——包括决定运行哪些脚本，而挂载 /usr 本身就是其中一个脚本，因此存在鸡生蛋还是蛋生鸡的悖论。
但啊，它并未如此！相反，整个系统环境必须确保在 systemd 启动前完成 /usr 挂载，从而免除 systemd 修复自身缺陷的必要。
个人而言，我并不介意 /usr/bin 与 /bin 合并，其优势在于消除了关于程序归属的争论(即该工具是否属于系统启动必需组件？)。
> sysvinit完全可以接受在/usr可用前挂载的指令[..]——只要你设置好在/usr可用前运行的init脚本
> 整个系统必须确保/usr挂载完成后systemd才能启动，这样systemd就无需修复自身缺陷。
尽管在我这个外行看来两者本质相同，但讽刺的是它们出现在同一篇帖子中。
区别在于，sysvinit 的作者们不会在启动时弹出令人讨厌的提示信息(https://systemd.io/SEPARATE_USR_IS_BROKEN/)，也不会试图改变文件系统标准。
前者如同“我按顺序执行脚本，其余全靠你自己”，后者则像“我包办一切，该做什么就做什么——你居然没挂载/usr目录？真丢人！这种边角案例我才懒得处理”
我解读这条信息是：“无论哪个倒霉鬼在尝试修复这个无法启动的系统(毕竟谁会去检查早期启动信息呢？)，安装这个系统的人显然在运行已知脆弱的配置。”
这难道就是我对systemd的期待？它本该在我、我试图运行的守护进程或整个系统以怪异、已知错误、已知脆弱的方式运作时大声抗议，并在可能的情况下提前预警，避免系统崩溃。
systemd就像一把锤子，对我要钉的钉子、钉的位置、钉入的材料以及钉入的原因都自有主张。
我只想把钉子歪歪扭扭地钉进一半，这纯属我的事。
锤子没必要评判我的钉法好坏——它只管敲。我不愿费心说服它接受那些它从未设想过、或曾考虑过却拒绝支持的使用场景。
我只想用那粗糙的衣架，管他谁喜欢谁不喜欢，管他谁建议我买个正规衣架按别人认可的方式安装。
> systemd就像那把锤子，对我的钉子——钉什么、钉哪儿、钉进什么、为什么钉——总有自己的主见。
我却恰恰相反。systemd的定制层级过于繁复。配置文件可能散落在/etc/systemd/system/、/run/systemd/system/、/usr/lib/systemd/system/*等目录下，这些还只是“基础”覆盖位置。而且这些修改和屏蔽通常互不冲突，因此即使系统其他部分变更，你的定制和特殊设置依然有效。
反观未使用 systemd 的系统，若你敢动那些“神圣不可侵犯”的系统服务召唤卷轴，每次卷轴更新后都得自己去比对维护者修改的内容，还要确保这个可能图灵完备的混乱代码仍能召唤出有效、安全且正常运行的系统组件，而非在系统中肆意破坏。
> 配置文件可存在于/etc/systemd/system/、/run/systemd/system/、/usr/lib/systemd/system/*等位置，这些仅是“基础”覆盖目录。这些编辑与屏蔽通常互不冲突，因此即使系统其他部分发生变化，你的定制与特殊设置依然有效。
我强烈建议您掌握这三类位置的差异。它们在语义上存在本质区别，系统能区分它们实属优势。当然，它们 都是 配置来源。但其中一类由操作系统供应商管理，一类由系统管理员管理，另一类则由运行时系统管理员管理。运行时虽非 同等 重要的区分点，但厂商配置与系统管理员配置间划清界限至关重要。
Systemd的诞生源于某位软件工程师的宣言：“你手里的不是锤子，而是木钉固定设备驱动程序…”
我们曾把这类人扔进护城河。
https://www-users.york.ac.uk/~ss44/joke/toast.htm
我可不想锤柄里嵌着剃须刀片，万一抓握“失误”，手掌就要被割得稀巴烂。
瞧，类比是双向的！
Poettering会坚称剃须刀片是他们愿景的一部分，反正systemd只支持现代的、抗剃须刀片的手掌。
这里根本不存在双向适用的类比。或许存在某种恰当的反向类比，但这绝非其一——因为在init这个锤子类比中，根本不存在刀片类比的握柄。
我选择锤子作为例证，因为init本质上就像一把锤子。它是一款极其简单的工具，功能范围有限，其行为特性完全可知且绝对可预测。它本身几乎不执行任何复杂操作，正因如此才拥有无限的灵活性。正因它没有自主意志，反而能让你实现比更复杂、更自动、更集成化的工具更多可能。
它不可能突然变成剃须刀片，因为它从一开始就没有配备剃须刀片或其他特殊功能。
你才是那个复杂的集成者。如果你不是，那么对于你承担责任时遇到的任何困难，我都不会表示同情。
你依然可以构建复杂的自动化与管理系统，其基础是更简单、更底层的 无关性 层级与工具。系统d所承诺的一切(实际上只是承诺，其表现并未优于其他方案)从未要求牺牲这种灵活性与优雅的前瞻性设计。
systemd更是紧密耦合的典型范例。令人费解的是，这些自诩天才的程序员竟会提交如此庞大的耦合系统——而他们明明都清楚，在稍有不同的场景下，这种设计正是需要避之唯恐不及的。
总体而言，systemd类项目要求用户扭曲系统以适应其预设逻辑，而sysvinit类项目则具备无限弹性以适配任何系统(通才无专精；劣者胜于优者；等等)。
systemd 的缔造者们还推出了 GNOME、PulseAudio 和 Wayland，这些项目共享相似的设计哲学。
顺带一提，多数 sysvinit 发行版几乎不使用 sysvinit 本身。sysvinit 作为服务监视器(类似 systemd 但更原始)，其配置主要用于启动时执行 shell 脚本。我们实际存在的是“systemd发行版”和“临时脚本发行版”，而非sysvinit发行版(“临时”并非贬义)。我不明白为何不直接将init设为shell脚本——这完全可行，且在初始化文件系统中通常如此实现。
> 总体而言，systemd类项目要求你调整系统以适应其预期，而sysvinit类项目则具备无限灵活性以适配任何系统(通才无专精；劣者胜于优者；等等)。
请举出一个在sysvinit(或“临时脚本”初始化)中能实现、而在systemd中无法实现的功能。使用 systemd 时，你依然完全自由地编写自己的手工编织的混乱脚本，并将其塞进原本整洁的单元结构中。
请列举一项在 systemd 中能实现、但在汇编代码中无法实现的功能
假设你的评论出于善意，但这种比较方式并不符合你试图论证的方向。
systemd(正常使用时)的抽象层次远高于脚本集合式的sysvinit。尤其由于systemd单元采用声明式设计，这种更高层次的抽象使系统管理员能更精确地指定所需行为。当然，你仍可通过systemd运行脚本，因此仍保有各种逃生通道。我的问题在于：sysvinit是否存在这些逃生通道无法充分覆盖的场景？
反观汇编语言，其运作抽象层级则低得多——事实上低得离谱。正因如此，你实际能精确指定所需行为的能力反而更弱。例如，你很难用汇编语言实现“在网络启动后、但依赖该Web服务器的其他软件启动前”启动Web服务器的场景。
不，问题在于它增加了不再必要的复杂性
尤其对基于镜像的系统而言更是麻烦
这包括用于Docker的OCI镜像
还包括基于镜像的发行版，例如 ostree(通过 rpm-ostree 应用于 Atomic Fedora 桌面系统如 Fedora Silverblue，Ubuntu 也在以类似但不同的形式进行实验)
若你使用完整 systemd 构建容器而非 pid0 适配层，那说明你用错了 systemd
你是不是误发到错误的评论区了？
你的评论似乎完全偏离了我的核心观点：当需要覆盖或扩展的组件分散甚至重复存在于多个位置时(而本可集中管理)，叠加镜像的操作将变得极其繁琐。
恰恰相反。虽然存储空间早已不是问题，但许多设备采用“网络/云优先”设计，通过互联网加载程序已成为现代趋势。这种设计显得尤为实用：核心二进制文件用于启动系统、连接网络，并在网络配置故障时提供调试支持；而其他程序则可按需从网络加载。
这只会徒增复杂性而毫无益处(至少如今如此)
对OS X而言无关紧要，其主要变革往往背离根源走向完全专有化
但对构建基于镜像的Linux发行版至关重要——这或许是Linux的未来
合并/usr是实现镜像化发行版的一种(日益被接受的？)方式。新系统版本对应新/usr分区。
macOS虽未合并/usr，但确实做了类似操作。
usrmerge 的目的之一是将系统的只读部分与可读写部分彻底分离。这有助于基于镜像的发行版——其中 /usr 目录可独立于只读文件系统存在——以及类似的应用场景[1]。虽然基于镜像的发行版运行时并不 必须 使用 usrmerge[2]，但它能使系统结构更清晰。
自2019年起，macOS同样属于“基于镜像的发行版”——其系统文件采用只读文件系统存储，用户数据则存放于独立的可读写文件系统中。然而其只读文件系统挂载于根目录而非/usr。为实现根目录下多个路径的可写性[3]，系统采用单一读写文件系统(/System/Volumes/Data)配合“硬链接”的方案——通过在只读文件系统路径与读写文件系统路径间建立硬链接实现。硬链接正是为此目的而设计的定制内核特性。
两种方案各有优劣。macOS方案的优势在于系统文件系统内包含_所有_只读文件/目录，而“/usr分区部署系统”方案则需在/目录下单独创建tmpfs来承载挂载点及指向/usr的符号链接。但后者能更清晰地向用户展示只读与可写文件的分离机制。相关地，macOS方案的缺点在于每个可写文件存在两个独立路径：一个包含/System/Volumes/Data，另一个则不含。而“发行版置于/usr”方案则存在相反缺陷——大量只读文件同样存在两个独立路径：一个包含/usr，另一个则不含。最后，macOS方案还需发明并使用firmlinks技术。Linux 虽可通过绑定挂载或 overlayfs 实现类似效果，但存在细微缺陷(绑定挂载的配置与撤销更繁琐；overlayfs 存在性能开销)。而物理链接也未必更优，因其缺乏明确的容器间共享方案(macOS 本身不支持此功能)。“发行版置于 /usr” 的方案无需此类复杂机制，实属可贵。
归根结底，双方的约束条件和动机截然不同。macOS 无法像 Linux 那样轻松实现单目录下的全读取权限，因为它除了 /usr 还存在 /System 分区。macOS 没有容器机制，也没有采用不同文件系统布局和部署机制的多发行版体系。从哲学层面看，尽管人们指责systemd偏离Unix设计原则，但systemd似乎自视为Unix设计的进化者，而macOS则倾向于将Unix视为某种遗留事物。systemd试图通过“/bin指向/usr/bin”等机制改进Unix并不令人意外，而macOS则选择保留Unix组件的原貌。
[1] https://lwn.net/Articles/890463/ [2] https://blog.verbum.org/2024/10/22/why-bootc-doesnt-require-… [3] https://eclecticlight.co/2023/07/22/how-macos-depends-on-fir…
我很高兴UAPI小组的“独立标准”假面终于破灭，其行为现在可直接归因于systemd的利益。
> 文件系统标准需要哪些持续维护？
适应大量细微的需求变更
– 当前存在截然不同的安全相关要求
– 性能相关要求/特性差异显著
– 各类边缘场景的需求差异显著
– 最后需根据实践验证效果调整方案
以下是文章未提及的示例：
– /boot 目录——若采用 efistub 启动则已废弃或用途改变
– /etc/X11 — 在Wayland环境下半死状态
– /etc/xml, /etc/sgml — 已废弃，个人认为本就不该存在
– 更关键的是：既然
/etc规范已默认包含X11等组件，为何还要将/etc/{X11,xml,sgml}明确写入标准？– `/media` — 视发行版而定处于半废弃状态，已被 `/run/media/{username}/{mount}` 取代
– `/sbin` — “争议性”目录；常有讨论认为其已无存在必要，且未达预期效果 对于老式瘦客户端，
/sbin位于存储设备而/bin挂载于其上时曾有实用价值。如今仍有极少数特殊场景适用，但多数情况属于“为解决其他类型问题而设计的权宜之计，应彻底修复根本问题”。– `/tmp` — “争议性”，长期存在安全隐患。采用程序专属`/tmp`目录可解决安全问题(如systemd服务的PrivateTmp选项)，但需建立“程序”概念而非仅关注“运行进程”(例如通过systemd服务或flatpack程序实现)。此外，
tmpfiles.d也能在此场景中发挥作用。– `/usr/libexec` — 已废弃，构想虽好但引入了不必要的复杂性，与 suid 等机制结合时极易造成误导
– `/usr/sbin` 参见 `/sbin`
– `/usr/share/{color,dict,man,misc,ppd,sgml,xml}` — 本不该列入标准目录，这些内容本应由 `/usr/share` 的定义隐含包含；至少 sgml 和 xml 已废弃。dict 原本用于拼写检查/自动补全，但如今两者均无法按 dict 预期工作
– `/var/account` — 仅适用于部分已淘汰程序的子集，不应纳入标准规范
– `/var/crash` — 发行版专属的混乱目录
– `/var/games` — 基本已废弃/安全隐患，当今99%的游戏都是用户自行安装(如Steam平台)，即使预打包游戏，其可变下载数据也属于用户专属，共享化将引发权限/安全混乱
– `/var/lock` — 如前所述，现今已有更优技术方案，例如使用 `flock` 替代“文件存在检测”等技术。此举还能避免程序崩溃后未清理“锁定文件”导致死锁，从而减少人工干预需求。
– `/var/mail` 采用相当过时的邮件管理模式，其特性高度依赖邮件程序本身。由于这种依赖性极强，我认为它不应纳入标准规范。
– 各类遗留程序特有的非通用文件系统要求，例如必须存在 `/usr/lib/sendmail` 且该目录需链接至兼容 sendmail 的程序等。
缺失部分：
– `/run/user/{uid}`
– `/var/run/user/{uid}`
– `/proc`
– `/sys`
– 用户侧版本(例如源自XDG规范，根据个人经验该规范也处于某种僵尸状态，如.config、.local/{bin,share})
– 轻量级沙箱相关条目，例如按程序分配的/temp目录等
– 工厂重置相关目录(
/usr/share/factory)，用于实现预装Linux设备的统一配置与设备定制化发行版(如Steam Deck)因此确实相当过时
> `/usr/libexec` — 已废弃，
绝非废弃，XDG门户和Polkit代理仍驻留于此。
取决于发行版，
但确实并非废弃，更像是为现代Linux系统增添无益的复杂性
“程序位于标准位置但不在路径中”这种需求还存在吗？
这可能取决于软件是否需要实施策略来阻止用户填满关键目录并导致系统异常运行——正如文章所述。这同时涉及协调问题，因为最常使用磁盘的其实是软件本身。
FHS似乎明确将磁盘填满的责任与后果归咎于用户。
更中立的表述应为：
> Debian政策仍引用FHS规范，而该规范已逾十年未更新。
> FHS 3.0显然已接近生命周期终点，甚至可能已过时。
观点有趣。
我认为FHS对软件包管理员、系统管理员等群体仍极具价值，能避免他们频繁踩踏彼此的领域。它有助于设定预期并防止不必要的意外。
仅因某条FHS规则过时甚至有害，并不意味着整个FHS体系已失去实用价值。
标准终究是把双刃剑。它们能让各方达成“最正确”方案的共识，却也冻结了技术演进。当标准无法适配当代使用场景时该如何应对？若其与现代安全实践直接冲突又当如何？
FHS多年未曾更新。而沙箱技术、容器技术、新型包管理方案等已成为时代潮流。FHS对此作何规定？
就这个具体用例而言，有人认为/var/lock目录对所有人可写构成不可接受的安全风险，但这很大程度上取决于具体环境和用户群体特征。在我看来，维护者似乎正试图缩减FHS范围，舍弃大量用例支持(这些用例在我看来相当合理，无需深入探究)。
> FHS对此有何规定？
在容器或沙箱内部遵循FHS规范并无障碍。
您指的是容器镜像存放位置吗？那么
/var/lib/containers/和/var/lib/containers/storage/完全符合FHS规范。关键在于当您不再遵循FHS时——就像systemd所做的那样。
Systemd 因 Poettering 对错误报告、传统和基本礼仪的完全漠视而令人沮丧和愤怒。与此同时，变革势在必行，变革必然伴随阵痛。重大变革不可能等到其稳定性与旧系统持平才实施：难道有人在职业生涯中会这样开发软件吗？我尽量避免发布完全垃圾的产品，但“达到 v1 版本的稳定性”从来不是目标。
> Systemd 因 Poettering 对错误报告、传统及基本礼仪的彻底漠视而令人沮丧和愤怒
Poettering 是微软员工。他遵循母公司的方向很正常。不正常的是他竟有如此多盲从者。
是又不是
每个发行版都定义了自己新的文件系统布局标准
虽然它们都源自FHS 3.0这个共同祖先，但此后分化程度各异
一些现代竞争标准试图修正这个问题(主要是UAPI组织)
(当然有人会纠结UAPI不过是systemd强加理念的手段，但若标准十余年[1]未更新，又抗拒他人接手维护——真不知该如何指责对方另立标准)
[1]：实际更接近20年，但10年前Linux基金会已接管其所有权。
Debian系统d维护者卢卡·博卡西近期强行推进多项争议性变更，将诸多问题性破坏性改动轻描淡写地归为“小众案例”——这种做法与我对Debian的期待背道而驰。
希望他们能改变这种处理方式。
这已是systemd维护者的常态。Poettering那句“我认为这不算什么大问题”堪称经典：https://github.com/systemd/systemd/issues/5644
没错，此人堪称傲慢之最的典范。早期设计复杂系统时确实成就斐然，但当这台过度设计的庞然大物遭遇现实问题时便开始辩护。systemd为提升灵活性已积累大量临时补丁，但愿终有一日能出现更优解。
每次使用Guix时，我都享受Shepherd的简洁性[1]
[1] https://shepherding.services/manual/html_node/Introduction.h…
有趣的巧合，两人竟都来自@Microsoft。
我们真要让微软员工为Debian制定标准吗？
显然是的，毕竟你评论的父帖已被标记。
个人认为这是个耐人寻味的现象——基于过去三十年的历史，微软对Linux的任何贡献都应持怀疑态度。
人们总在微软抛出骨头时立刻抹去其过错，这背后存在某种耐人寻味的心理机制。
更何况微软在Windows 11中对用户实施了各种滥用行为。
我认为不该如此，因为微软似乎天生擅长将系统、界面等复杂化。更别提他们几年前还试图打压Linux(甚至通过代理手段！)。指望他们做出符合Unix精神的正确选择，实在缺乏常识。
情况很复杂。微软确实投入了资源，他们有能力这么做，但这种奢侈只源于他们作为践踏用户的巨型企业。
若能确信他们投入资源时绝不会滥用未来获取的权限与影响力，或许尚可接受——但我们无法确信。
试问：洛克希德公司是否该刻意低价雇佣朝鲜程序员？只因朝鲜有能力投入资源协助洛克希德？核心问题并非朝鲜是践踏公民的超级大国，而是洛克希德的利益与朝鲜根本不相容。
Debian的目标由贡献者共同决定。若微软参与贡献，利益便不可能相悖——这正是开放的真谛。你或许不认同这种影响，但若拒绝微软参与，就等同于背离真正的开放精神。
个人倾向于优先处理符合雇主利益的工作，但这并不意味着他们能恣意妄为。这只是将精力和关注点转向特定领域。除非某公司雇佣了大量Debian维护者(微软并非如此)，否则这根本不成问题。
不，Debian有其独立使命，历来会排除反对该使命的开发者候选人。它从未如你想象的那般开放。
https://www.debian.org/intro/philosophy
我认为聘请systemd项目负责人能让微软获得某种影响力，而聘请libjpeg-turbo打包人员则无法做到。Lennart以专断行事而臭名昭著，而我们讨论的重点在于：负责systemd的Debian软件包维护者同样在专断行事，且同样受雇于微软。
当微软同时开发竞争性操作系统时，这种安排如何运作？
若从逻辑角度思考，他们可能通过损害核心用户群利益的“决策”来破坏Debian。
这类似于欧盟怀疑论者——正是这些人制定了欧盟内部极不受欢迎的法律，导致欧盟饱受负面舆论。但他们作为民选代表必须被倾听，毕竟这是民主体制。
不，我们不必如此。
我认识的资深用户没有一个没被systemd的蠢设计坑过。至今仍恨透了那个默认行为——在Lennart自以为是之前，未限定名称的stub-resolver明明“一直正常工作”。
我从事Linux系统管理已有十年。我从未遇到过systemd的问题，也不认为它愚蠢。显然你可以不喜欢它，但你这种一概而论的做法未免太过武断。
这难道不意味着你是在systemd广泛采用后才成为系统管理员的吗？大多数讨厌它的人很可能在systemd出现前就积极参与过Linux开发。
这取决于你所说的“从事这行”具体指什么？
虽然现在工作要求“使用Linux必须是Ubuntu”(我遵从了)，但在个人层面——大约十年前我从“原生”Gentoo迁移到Calculate Linux，后者当时和现在都是100%基于Gentoo的系统。
如今两者差异更小了，但早在十多年前，Calculate就已具备合理的配置文件体系，所有软件包都以预编译二进制形式匹配这些配置。
尽管systemd是Calculate/Gentoo可配置的USE关键字之一，但它至今仍非默认选项。
所以可能确实存在完全未接触过systemd的人群…至少目前如此。
此人根本不懂通配符原理，却在未经测试、未研读规范(更遑论理解)的情况下，自以为凭臆测就足够可靠。
公平地说，他确实了解通配符机制：“.*”按常规规则应包含“.‘和’..”。'rm'命令(推测)设有特殊机制，避免递归模式下遍历这些路径——否则将引发灾难性后果。
公平地说，符合POSIX标准的shell被允许排除
.和..，部分实现确实如此，且POSIX规范指出未来可能强制要求此特性。https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V…
幸好过去十年他们更新了规范……等等。嗯。看来标准的这一部分已被废弃。我们应该制定新标准！
相关驳斥链接：https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112535#64
这里还有个有趣的讨论串，因他与技术委员会的争执导致 systemd-resolved 被移出 debian-testing 分支： https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101532
毋庸置疑，此类行为最终损害的是用户利益。
哇，要是我在工作中这么做，绝对会被当场开除。
更令人发指的是，他竟因个人情绪拒绝提交补丁——
若想使用Debian系统又排斥systemd，Devuan是个选择。不过我怀疑“原生”非systemd发行版会更稳定，个人用Guix就挺满意。
https://www.devuan.org
我家用这系统四年了，运行很顺畅。
Debian 目前仍可完美运行于无 systemd 环境(至少现阶段如此)，不过 Devuan 确实能让操作更轻松。
能否解释为何 systemd 开发者如此肆意妄为地推行其理念，甚至用理念之杖胁迫众人？
在此情况下，我认为上游维护者的回应——“上游systemd将执行X操作，发行版若需可自由选择Y方案”——是合理的。反观若systemd强制要求可写入的/run/lock目录，那么追求更高安全性的发行版将无法实现目标(或被迫实施更具侵入性的补丁)。
从外部观察来看，这更像是Debian系统d包维护者未能遵循Debian规则所致。(不过由于我并非该社区成员，我承认可能存在我未曾了解的文化期望。)
> “上游systemd将执行X操作，发行版若有需要可自由执行Y操作”
是的，这是上游的合理回应。我能接受这种处理方式，但即便如此，该回应仍未在邮件列表讨论中得到体现，或被立即淹没。
不过我的质疑更具普遍性，旨在审视systemd开发者群体(即项目行为)历来的整体表现。
systemd开发者长期存在重复造轮子并强加于人的问题。我们之所以容忍他们，只是因为他们承担了无人愿做的艰巨工作。
那你自己说吧。我从2004年使用Linux至今，systemd组件终于让系统管理变得轻松。再也不用搞那些晦涩的初始化脚本，服务依赖关系处理得当，定时器机制完善，配置文件简洁明了，管理知识能在所有系统间无缝迁移。
作为用户，systemd极大提升了我的工作效率。
那些对解决复杂问题、运行于数十亿台机器的代码大加挞伐的开发者，暴露的更多是你自己脆弱的自尊心，而非他们的过错。
> systemd开发者长期存在重复造轮子并强加于人的问题。我们之所以容忍他们，只因他们承担了无人愿做的艰巨工作。
> 作为用户，systemd极大提升了我的工作效率。
这两种观点可以同时成立。尤其在初期，系统d破坏了许多原本“直接工作”的重要功能，例如：
1. 将家目录挂载在自动挂载的NFS上。在sysv时代，autofs会等待网络就绪后才启动。而系统d最初将“本地主机可用”视为网络就绪状态。
2. 在SSH会话中输入“exit”后能正常断开连接。systemd会通过kill -9终止登录shell时所有该用户ID的进程，包括处理连接的sshd进程——且在该进程关闭连接套接字之前。这意味着交互式终端输入“exit”后会陷入死挂状态。
虽然我已很久未遇到系统d的重大问题，但最初几年曾出现大量关键功能故障——那些原本“开箱即用”的功能突然失效，修复过程却因问题未波及系统d维护者而拖延良久。若你未曾遭遇这些问题，很可能只是因为你的使用场景恰好与维护者重合。
诚然，systemd和journalctl极大简化了我的工作。但本可以以更小的破坏性实现这些改进。
我最喜欢的systemd漏洞是网络黑洞状态(非断连，SYN数据包有效但其他数据无法返回)。此时整个系统将彻底卡死。
必备XKCD梗图：https://xkcd.com/438
不必如此粗鲁。我虽不反系统d，但它确实没给我带来翻天覆地的改变。
人们总爱抨击init脚本，但精心编写的脚本既能稳定运行，又能在不同系统间轻松移植。至少在我管理的机群中是如此。
依我经验，Parallel-SysV的依赖管理同样相当出色。况且systemd的运行速度并不比Parallel-SysV更快。
也并非什么“被迫从零学习”的苦情戏码。我属于那种从不抱怨、只埋头研读文档的开发者/系统管理员类型。
在Debian迁移期间，我编写了海量服务文件和初始化脚本。当时我还担任某Debian衍生版本的技术负责人(尽管工作环境堪称地下室级别)。
systemd及其开发者历经诸多阶段，屡屡重蹈覆辙——即便被反复警示仍犯下错误，至少两次误入歧途，并因正当理由遭到众矢之的。
他们招致的愤怒并非毫无根据，但我认为他们不该成为口水战的靶子。
在我看来，systemd开发者若能放下高姿态，与用户平等对话，将获益匪浅。彼此友善从不会伤害任何人，包括你们自己。
世间万物皆是他人成果的微调。但要让事物协同运作仍需付出努力。systemd或许没有新奇技巧，却能实现绝佳协同。标准化同样极大简化了许多人的工作。否则若人人都在重复发明轮子，某些集成必然会失效或运行不畅。模块化固然美好，但并非免费。
你觉得systemd可能是心理战？通过付钱让开发者做那些丑陋但必要的工作来获取影响力，同时又在背后散播大量分歧…
我早就对浏览器大战有过类似想法。哪些项目属于心理战，就留给读者自己琢磨吧。
Linux已有34年历史，其中借鉴的某些Unix特性更为古老。确实存在弊端的陈旧代码。在向后兼容性、可维护性及遗留问题引发的各类矛盾中权衡轻重，实属合理。
systemd本质上源于对遗留问题的挫败感，整个项目本质是现代化改造工程。难怪他们将向后兼容性置于次要地位。
这本就是他们一贯的行事方式；既然行之有效，何必改变策略？
systemd的核心问题在于它不愿让你按自己的方式行事，而是要求你服从其规则。
Linux的核心问题在于强迫你将一切(包括设备和I/O)都视为文件。我宁愿坚持使用MS-DOS——至少还能亲自操作内存来控制硬件。/s我的观点是：系统间的契约能改善我们的生活。如今我们已将进程、文件和受保护内存模型视为理所当然。不过我敢肯定，当年人们同样痛恨向保护式系统迁移，因为它“限制了自由操作”
因为这本就是他们的惯用方式，且至今仍行之有效？
Systemd虽不合我意，却已席卷多数Linux发行版，显然它具备我未能理解的吸引力。PulseAudio当初也是如此。
你读的是同一篇文章吗？
我认为所有相关方都更希望通过应用程序更新来修复问题。Debian当前选择保障用户可靠性，这符合其使命宣言。在Arch系统中，/usr/bin/run/lock*目录仅超级用户可写，这提升了安全性。作为用户，我重视可靠性与安全性，同时希望传统工具保持可用性(有时默认启用，有时通过开关切换)。
> 这属于安全问题
所谓“安全问题”指的是有人创建40亿个锁定文件。应用程序需要路径创建这些锁定文件的根本原因，在于其正在处理共享资源。锁定文件绝非应用程序导致系统崩溃的唯一途径，这也正是为何无人将此“安全问题”当回事。
若细究字里行间，其动机更显露无遗：Systemd企图掌控“/run”目录，却不愿容忍用户空间应用程序在其资源池中活动。值得注意的是，他们对/var/tmp等目录却未表现出同等的安全顾虑。
他们不愿容忍用户空间应用程序在其资源池中活动
我认为这多少有些道理。但既然如此，systemd就该拥有独立于共享空间的专属区域：/var/systemd/run 或 /run/systemd/？
> 那么systemd就该拥有独立于共享空间的专属区域
这将违背其未明言的目标：迫使所有其他组件为systemd的节奏起舞——当然，这都是为了它们好。
虽未明言，但显而易见。早有先例：[0][1]
[0] <https://lore.kernel.org/all/20140402144219.4cafbe37@gandalf….>
[1] <https://lore.kernel.org/all/CA+55aFzCGQ-jk8ar4tiQEHCUoOPQzr-…>
> 在 Arch 系统中，/run/lock 目录仅对超级用户可写，这提升了安全性。
是这样吗？这意味着任何需要锁定操作的人都必须获得超级用户权限，似乎有些过度了。设置一个具有写入权限的组似乎更能提升安全性？
不，这完全不是这个意思
全局的/run/lock目录是过时的机制，现已不再需要
标准制定时(20年前)旨在规范程序绕过缺乏flock机制的通用方案。这在FHS 3.0的具体要求中亦有体现：锁定文件必须命名为
LCK..{设备名称}，且需以特定编码格式包含进程ID。有趣的是—— Flock功能约于1996年引入Linux，因此即便在标准制定时已显露过时迹象，多数程序转向Flock只是时间问题。由此可见该问题存在两大逻辑漏洞：
– /var/lock目录的大量使用场景已被Flock取代
– 因此任何不希望使用 flock 的普通用户程序，都应将锁定文件放置于
/run/user/{uid}目录下，例如 pipewire、wayland、docker 等程序的做法(具体而言即 $XDG_RUNTIME_DIR，该目录恰好为/run/user/{uid})。因此受此影响的程序仅限于：
– 非以root身份运行的程序
– 未使用flock机制的程序
– 且未遵循XDG标准引入的最佳实践
– 需注意：鉴于长期以来消除全局可写目录的努力，/var/lock受限或被移除实属意料之中
换言之，这类软件仍停留在上个世纪——更确切地说，是停留在两百年前的2000年代
但这在Debian稳定版中屡见不鲜——即便要移除二十年前就被认定为糟糕设计的组件，也需费尽周折。若非Debian的声誉使然，我猜systemd开发者对此问题的震惊程度，恐怕会超过Debian维护者对某些使用过时机制的冷门工具崩溃的反应。
> 软件停留在上个世纪
好吧，但假设你需要运行某个停留在上个世纪的软件，且无法修改它：或许你缺乏技术能力，或许你甚至无法访问源代码。你会选择以root身份运行，还是以某个有权写入该目录的组成员身份运行？
systemd维护者(包括上游开发者和Debian包维护者)长期以来总想忽略那些他们觉得麻烦的使用场景。
绝大多数老旧软件都依赖众多组件，因此你往往不得不将其部署在搭载旧版Linux内核+发行版的虚拟机中运行
若无法实现，也可将其封装在容器内，将
/var/lock目录权限改为非root专属。对于任何弃用软件，你本就该采取这种做法。我认为以下三点成立：
软件可以是完整的。
软件的完整性具有美德。它让我们得以解放时间去从事其他事务。
仅因个人对“自行车棚”的改造而强制要求修改软件，则不具美德。
此言极是，兼容性实乃恩赐。软件不应每月都需要更新，这恰是其品质的体现。
长期以来，/var/lock的使用方式确实笨拙。而API清理不力则会催生如Windows般糟糕的产物。API变更应严格限制在绝对必要的最小范围内。值得庆幸的是，在Linux平台我们通常能通过代码适配与修补来应对。
另一方面，Linux内核、GLIBC/STDLIBC++、Systemd和Wayland必须保持API稳定。没人喜欢API不稳定。
不，我没读完整篇文章。我直接关注debian-devel邮件列表，全程见证了这个问题的逐步展开。从它发布到debian-devel那天起，我就知道最终解决方案。
这最初只是个普遍性问题。
> 其实存在保留旧行为的选项。
讨论焦点从未围绕“基于正当理由保留旧行为”的选项展开。整体基调是“systemd要求如此，Debian就该遵从”。这几乎演变成理性派与另一派之间的口水战——后者只会高喊“我们说了算！”
> 这是安全问题，且已有现代替代方案。
我虽是Linux新手，但使用Linux已有23年，专业管理经验超过20年。至今未见过任何攻击利用/var/lock目录的全球写权限。根据我的经验，/dev/shm才是更大的攻击面。
迁移至flock(2)并非坏主意，但像尼禄般纵火焚烧邮件列表绝非良策。人们本可合作共进，某些人却热衷于泼冷水、制造麻烦，只因他们认为自身要求必须立即服从。
> FHS已无人维护。
是无人维护，还是改进速度无法满足systemd开发者？不得而知。许多支撑大量系统的标准和RFC同样长期未更新。
我们更倾向称其为“成熟”而非“弃置”。
> 在Arch系统中，/run/lock仅对超级用户可写。作为普通用户，我更重视可靠性，而传统工具完全可用。
我也重视可靠性，并认同传统工具应持续运行。这正是我二十余年来始终主要使用Debian的原因。
我的意思是，早在二十年前制定FHS3规范时，/var/lock就已面临被取代的命运。我们同样清楚这个设计缺陷已存在相当长的时间。
如果FHS没有被搁置近二十年，我敢肯定非root权限的/var/lock目录早在十多年前就该被废弃(或至少被建议停止使用)。几十年来我们都知道跨用户可写全局目录是个糟糕的主意，如果连这都修不好，说实话我实在看不到Linux的未来。(1)
诚然systemd本应提前预警，临时回滚变更设置过渡期也合情合理。但这项变革酝酿已逾二十载，长远来看实无回避之法。
(1): 这听起来或许荒谬，但安全需求确在演变。2000年时信任多数运行程序尚无大碍。如今则不然，你几乎无法信任任何运行程序。若继续信任核心操作系统组件之外的任何内容，迟早会构成法律意义上的疏忽(即法律责任)，即便信任核心组件也需设限。尽管令人沮丧，但Linux若不适应变革就会消亡。它确实有所适应，但主要发生在GPG/FSF生态圈之外，而且我认为桌面领域的变革步伐稍显迟缓。这让我相当忧心。
> > FHS已无人维护。 > 是完全停更？还是改进速度跟不上systemd开发者的要求？我不确定。
更准确地说，在周边环境需求剧变的背景下，这个标准二十多年毫无更新。
他们甚至没修正/var/lock的定义规范。他们声称该目录可存放各类锁定文件，却同时规定必须遵循命名规范——该规范仅适用于设备文件，且仅限于非子目录结构中的文件。规范还未明确指出(或至少未允许)重启时清除该目录(他们对临时目录有此说明)。脚注中还声称所有锁定文件应为世界可读，但这一说法早已失效。某些锁定文件组(同样未在规范中提及)本就不需要或不应公开，因为它们仅泄露攻击者可能在某些冷门场景下利用的细节。
成熟的标准应包含修正、改进和澄清，包括针对使用环境变化的调整。成熟标准应能识别次优设计，添加警告并建议避免使用此类设计。但该标准从未经历过此类演进。
我们看到的标准不仅二十年未获实质更新，甚至未能修正自身矛盾之处。
标准要走向成熟需要经历成长过程：修正矛盾、补充说明、标记弃用(这并不意味着后续会移除)。而这些已久未发生。使用时间长久并不等于成熟。
若要吹毛求疵，连Debian也未能“完全”符合FH3标准——其中某些条款早已不合时宜，却二十年未曾修正。
> 2000年时信任多数运行程序尚无大碍。
没错。正因如此微软才未将Windows XP基于NT内核开发，而Windows 95不过是在Windows 3.11基础上披了层(或许相当)漂亮的涂层。
这也解释了为何在NT问世前的数十年间，从未出现过采用复杂权限系统、在隔离虚拟地址空间中运行进程的多用户系统。当时所有操作系统研究者和系统管理员都认为，没有理由怀疑其他用户计划运行的程序。
不过主要作者确实供职于微软
这家把“同意”视为禁忌词的公司
大概是因为大家都纵容他们继续这么做。
每当有人批评systemd，总会有人迅速反驳：“但以前用其他初始化系统开发太难了，别抱怨了”。
所以从一开始，systemd及其开发者就获得了足够宽容——毕竟它始终是强加于我们的。
我猜他们所谓的“担忧”，是害怕普通用户耗尽关键tmpfs的资源(inodes、文件系统空间)导致系统崩溃。要实现向后兼容，正确方案或许是让/run/lock成为独立挂载点，但他们在自家系统(Fedora)里修补了这个问题，现在就不再是他们的麻烦了。你该庆幸他们的软件还能移植到Debian这种冷门操作系统上。/s
有趣的是，在Luca决定废弃它之前，这 曾经 是独立的文件系统。https://lwn.net/Articles/1041948/
在发泄之前先声明：得益于虚拟机监控程序、虚拟机、非systemd发行版、Talos这类最小化不可变Linux发行版(为以最少可执行文件运行Kubernetes而设计)以及OCI容器(其定义中PID 1并非systemd)，我们终于能在Linux架构中真正摆脱systemd的束缚。
我认为更多人应当重新考虑彻底摆脱systemd的束缚。
> 能否有人解释为何systemd开发者如此肆意妄为地推行其理念，并用思想大棒胁迫所有人？
因为他们的 目标 是掌控Linux。这正是systemd成为PID1的缘由，也是Poettering投身微软的动机。
真正的问题是：为何那极其复杂的xz后门攻击仅在安装systemd的Linux系统上生效？有人会转移视线声称 “这只是因为OpenSSH加载了xz，与systemd无关”。但这 完全 与systemd有关。
另一个问题是：当前有多少后门正在系统d环境中运行？
系统d堪比微软级别的臃肿软件，以PID 1身份运行，在Linux发行版中肆意扩张触角，这绝非偶然。
更令人发指的是，波特林再次暴露了其令人难以忍受的霸凌本性。
原文引述：
> 那么你建议如何推进？修改Debian政策(如#1111839所提)、撤销systemd变更、寻找Debian全局解决方案，还是让每个包维护者自行实现？
我建议Debian彻底放弃systemd。虽然仍可实现无systemd的Debian，但过程相当麻烦。让Debian重新回归无systemd状态。
在此期间，你会发现我在虚拟机上运行无systemd发行版，用容器给systemd的PID 1比出中指。
我迫不及待想把Proxmox迁移到FreeBSD的bhyve虚拟机管理程序(得抽时间搞定)。
但最令我期待的是：Proxmox这类无systemd的超虚拟化Linux系统问世之日。
它终将到来，那些鼓吹“别用Docker，用systemd如何如何”的人实属误入歧途。
systemd于我而言，正是Linux精神的反面。
但愿Debian某天能彻底厌倦systemd而将其弃用。
附注：我有一台机器运行这个：https://www.devuan.org/，坦白说完全没问题。所以没错：向所有运行无systemd发行版、BSD等系统的用户致敬。
[已删除]
哦，所以只要我们说得对就能打人鼻子？
这倒是新鲜事。
万一对方也对呢？我们岂不是要打起来？
大家能不能讨论问题，别互相欺负？
会编程不代表就能粗鲁无礼。
另一冲突：在Debian Trixie(当前稳定版)中，执行
systemctl status ...会触发令人不安的警告：这是因为Debian将/usr/bin与/usr/sbin分开管理。目前系统维护者无意取消该警告，Debian维护者亦无意修复，且两方均无计划合并/usr/sbin与/usr/bin目录。
于是荒谬的局面就此形成：Debian用户被告知其默认干净安装环境竟被核心初始化系统标记为“降级”且“受污染”！
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370
https://github.com/systemd/systemd/issues/35438
若情况属实，我惊讶于竟无人从源代码中移除这个反功能。双方都在你链接的错误报告中直接提出了这个建议。我认为实现补丁应该轻而易举，但必须有人挺身而出完成这项工作。
systemd上游表示“发行版若愿意可自行修复”，而Debian包维护者不愿提供补丁。“需要有人编写补丁”并非当前症结所在。
哎呀。我误解了Luca回复中接受补丁的意愿，但他实际上要求提交给上游——而上游明确表示不接受。所以，没错，陷入僵局了。
有人推进过这个议题吗？若补丁已存在且上游明确要求其归属发行版，那么维护者就该详细说明：究竟是补丁不适用/不可维护，还是维持现状更妥当。
至今仍无法理解为何众人竟普遍采用systemd——它堪称史上最自私、最鲁莽、最不负责任的维护案例。这并非新问题，这种状况持续了多久？十年？十五年？
好久没听到uucico(Unix-to-Unix Copy-In Copy-Out程序，UUCP套件组件)的消息了。欣慰它仍在发行！不知还有哪个网络在使用它。
过去一两年我一直在运行它，用于向一个装有UUCP软件包的老式DOS BBS发送邮件。令人惊喜的是它在CentOS和Debian上都能开箱即用，而且Postfix至今仍附带示例UUCP邮件配置文件。
非标题党标题——Debian技术委员会推翻/run/lock权限变更
更具标题党风格——Debian技术委员会告诫蠢萌维护者们别再对Poettering顶礼膜拜
“DTC给两位系统维护者吃瘪，他们早有收受微软资金的前科”
且此举可能仅为临时措施
当前覆盖确实合理，需设置过渡期等安排
但我们身处这样的世界：操作系统必须日益增强对异常程序的容错能力(主要指用户程序，或可通过服务/服务账户隔离的“服务器程序”)。随着供应链攻击与低劣AI代码的持续增加，这种趋势只会愈演愈烈。
因此，像lvm2和dmraid这类共享临时文件系统的用户空间程序采用配额/使用限制机制实属不智。
要实现这种稳健性，可行的替代方案其实有限，基本选择包括：
– 将/var/lock设为仅限root访问，这会破坏极少数既不使用flock也不遵循XDG规范的程序(XDG_RUNTIME_DIR才是用户级锁定目录，例如Wayland或Pipewire使用的锁定位置)
– 修改 lvm2、dmraid、alsa(底层组件)及其他核心操作系统组件，使其使用不同的 root 专属锁定目录。这将带来大量工作和破坏性变更，远超第一种方案。
– 采用“魔法”虚拟文件系统，对外呈现统一的/var/lock视图，但底层会神奇地将锁分隔到不同配额的临时文件系统中(例如根据用户ID将文件重映射到/run/user/{uid}，根目录有专属文件夹，其余内容可能另设文件夹？) 这似乎是为极少数采用极其过时(20+年)方式的程序，构建了过度复杂的支撑方案。不过类似技巧在systemd中确实存在(如PrivateTemp)。
似乎只有第一种方案合理
但并非必须“立即”实施，一年后推进也无妨，五年后则可能为时已晚
这怎么不算标题党？老实说“Debian技术委员会推翻systemd对/run/lock权限变更”可能比这两个标题都更合适，我分不清这里更吸引人的是事件本身还是参与者。但标题终究篇幅有限。
是啊。我本以为LWN能做得更好。
我认为真正有趣的不是具体的技术变更，而是人际层面的——推翻维护者的决策。
因此标题恰恰反映了故事最精彩的部分。
所谓“有人可能通过/run恶意耗尽内存”的论调在我看来很可笑…通过tmpfs挂载选项设置硬性大小限制轻而易举。就算绞尽脑汁钻研，当/run空间耗尽后无法创建新文件，勉强算作拒绝服务攻击——但拜托…
tmpfs支持配额功能！我赶紧躲到桌子底下免遭水果袭击
问题在于/var/lock仍被各类系统根组件使用。
包括lvm2、dmraid和音频驱动等服务。
因此至少需要为“根用户”和其他用户分别设置独立的/var/lock目录。
现在有两种选择：要么修复所有根工具使其使用不同锁定目录(这会破坏大量功能)，
要么破坏极少数非常老旧的工具——这些工具(大多)既不使用1996年推出的flock机制，也不遵循2003年制定的XDG规范(XDF_RUNTIME_DIR)。
显然该如何选择不言而喻；关键在于需要更完善的协调与沟通机制。
毫无疑问，XDF_RUNTIME_DIR下的临时文件系统必须启用配额机制——至少能让系统更稳健地抵御异常程序的破坏。
需要明确的是，自2000年代起，许多安全顾虑在多线程模型中已变得无关紧要或被忽视。但时代(遗憾地)已然变迁，我们不应再盲目信任用户空间程序。即便忽略恶意程序，仅考虑人工智能可能引入的各类漏洞就足以令人担忧。坦白说，我担心桌面Linux将无法适应这些变革。服务器Linux显然正在转型，尤其在非GNU Linux生态中更为显著，而更具FSF/GNU特质的Linux部分似乎仍停留在过去——那样的未来显然已不复存在。这无疑令人沮丧，但我实在难以想象在没有大量供应链攻击和AI编码引发的用户空间程序疯狂异常行为的未来。
PS：即使你只想要一台具备主机级稳定性的Steam Deck(即游戏崩溃时也难以彻底卡死主机，无论它如何运行，你总能按下菜单键关闭/终止程序)，这类细微调整仍是必需的。还有许多其他改进。
> 包括LVM2、dmraid和音频驱动等服务。
至少前两者具备“忽略锁定”命令行参数，可解决/run目录空间不足等困境。因此是否构成系统崩溃取决于你如何定义崩溃 🙂
> 关键在于需要更完善的协调机制和沟通渠道
我的意思是，这确实需要改进。但问题严重到必须立刻破坏用户体验吗？在我看来并非如此…
若非内存文件系统，用户仍可能耗尽磁盘空间，这与当前机制有何本质区别？
哇，这简直是小题大做。
让上游的systemd单方面定义发行版中目录的存在与权限模式，从来就不是预期的运作模式。
Debian为此提供了海量软件包，显然在维护与所有软件的兼容性方面会面临更多难题。
对Debian而言这本是轻而易举的事，系统d只需专注当前要务即可。这种讨论竟出现在非相关邮件列表里…难道本周Linux新闻太冷清了？
他们本就不该接纳systemd进入Debian，更不该让其他潜伏者垄断RH/IBM的技术知识，从而转移对原生软件包(GNOME、Wayland、Podman，甚至RPM等)的关注。
ulimit和配额机制能否充分解决此问题？
有人惊讶于systemd团队基本对所有人说“去你的，我们想怎么做就怎么做”吗？
> 有人惊讶于systemd团队基本对所有人说“去你的，我们想怎么做就怎么做”吗？
我认为这并非准确表述。更准确的说法是：“这更像是上游systemd向下游项目传递接力棒：若发行版需要此类传统接口，只需通过发行版专属的tmpfiles插件实现。但强迫那些具有前瞻视野的项目继续保留该目录实无意义。”
这种替换方案本就司空见惯，实在不明白为何如今竟成了众人热议的焦点。
确实如此，但问题在于卢卡既是systemd开发者又是Debian开发者，因此这里并未真正实现接力传递。
不，我一点都不惊讶
正如我下面要解释的，这项变更迟早必须实施，所有替代方案都明显更糟
此外，Debian的处理方式与主流软件开发模式存在根本冲突。比如在时间上不切实际的要求——比如期待小型开源团队发布长期支持版本，或回溯移植那些已通过重写/破坏性变更修复的漏洞。更别提诸如将过时版本的软件与本不兼容的依赖版本捆绑发布这类荒谬操作。后者不仅会导致已修复的漏洞反复被提交(而你根本无暇处理)，还会引发在任何“受支持”版本组合下本不该出现的错误。因此许多软件从“确保兼容所有发行版”转向“确保兼容上游版本的近似分支，其余情况用户自行解决”。
这便引出了本次沟通不畅的讨论：
– 基于以下原因，systemd宣称“上游将按此方式推进，不接受讨论”实属合理
– 但Debian选择优先保障向后兼容性而非追求极致稳健性同样合理，至少应为其设置较长的过渡期
– systemd确实应在发布变更前告知Debian，避免引发兼容性问题
– 但任何Debian维护者若认为自己有权强制systemd撤销变更，都显得过于僭越
– 而任何 systemd 开发者声称 Debian 不得在其发行版中回滚变更同样是强人所难(毕竟这不太可能导致本不会出现的 systemd 缺陷报告)
因此存在大量沟通失误。但无论“不顾 Debian 态度强行变更”的决策，还是“因不满而回滚变更”的决策，在我看来本质上都相当合理
—
/var/lock 由 lvm2 和 dmraid 等核心组件共享，其 inode 耗尽属于严重问题
2000年时，对用户空间程序的异常行为不必过度关注尚可接受；但到2025年，这已成为关键安全隐患(原因有三：1)对系统弹性/可靠性的要求更高；2)恶意代码、供应链攻击等威胁增多；3)意外异常行为/低质量代码激增)。因此必须解决此问题。
我提出三种解决方案：
禁止所有非root程序使用/var/lock目录，但这将带来大量工作和破坏性变更。
将/var/lock设为root专属目录，毕竟自flock(1996年)、XDG_RUNTIME_DIR(2003年)乃至/run/user/{uid}(约7年前)出现后，用户程序本就不该再使用该目录。除非破坏一些使用20年前过时方案的小型软件，否则不会有问题。
第三种方案是构建某种神奇的虚拟文件系统代理，根据所有者用户ID动态映射到不同临时文件系统实例。但为少数极旧软件维护这种复杂且可能存在安全漏洞的系统，真的值得吗？
实际上只有systemd的解决方案真正合理。Debian或许会青睐第三种方案——前提是systemd能代为维护，因此这并非可行选项(Debian完全可自行开发维护，无需深度集成systemd)。
现实中仅存唯一解决方案，若无更优方案，仅凭“我不喜欢，别这么做”的抗议无法改变现状。
系统开发者受雇于需要这些功能的企业，实际上多数公司都渴望这种深度增强的健壮性。因为服务器避免一次死机带来的收益，往往远超只读/var/lock带来的成本(多数情况下根本不存在成本)。甚至桌面系统也能从中获益。至于少数仍需旧版/var/lock的企业系统，完全可以像Debian那样进行修改。
此处所谓的“其他人”基本仅指Debian生态圈——他们执意沿用1980年代的串行锁定策略。Debian若想以苏联委员会的效率推进固然无妨，但要求systemd同步这种步调既不合理也不健康。
软件开发者的首要职责是为用户开发软件，而非迎合第三方分发商的打包要求。
争议焦点不在于systemd上游——他们早已提供简单无趣的解决方案——而在于Debian包维护者(某些人身兼数职)。
Debian存在的根本意义正是以这种节奏推进，优先保障稳定性/兼容性。若不认同此理念，用户大可选择其他发行版——但包维护者的首要职责是为该发行版重新打包软件(用户选择该发行版必然有其考量)，而非迎合上游。
文章最后一段提到Fedora如何通过lockdev(3)解决该问题。我不明白：既然库文件提供了标准化的锁管理接口，为何非root用户无需全局可写锁定目录就能创建锁？难道是lockdev(3)允许系统使用其他目录？
其次，文中暗示/run/lock目录及共享资源锁定方案已过时——但未提及“现代”解决方案？是否暗示systemd提供了替代方案？具体是什么？
附注：lockdev的手册页写得实在糟糕。
总觉得，若把耗费在争论讨论上的时间都用来修补受影响的应用程序，问题本可 彻底 解决。
我明白，系统d糟糕，民主机制优秀，但这些全局可写锁定目录确实令人头疼。添加些转换代码升级到更安全的方案，难道不可行吗？
真心好奇——为什么全局可写目录会损害安全性？当然前提是它位于独立文件系统且挂载选项合理。以下是我在sid系统中执行“grep /run/lock /proc/mounts”的输出：
经典案例是：假设你知道某个root进程会在/run/lock目录下写入名为foo.lock的文件，而你(恶意用户)恰好拥有该目录的写权限。此时若将foo.lock改为指向某个文件的符号链接(例如/bin/init或/bin/sh或ld.so这类极不方便的选择)，当root进程写入锁定文件时就会破坏目标文件。
当然如今人们普遍了解此漏洞，通常不会使用可预测的文件名，但这确实是一种攻击方式。
> 当root进程写入锁定时会破坏该文件。
除非你采用open(“/run/lock/foo.lock”, O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW)这种方式操作
没错。为了保险起见，先用O_CREAT模式创建随机名称的临时文件，再通过rename()将其重命名为可预测的“foo.lock”。
两位说得都对。但我想强调的是，以root身份运行shell脚本(尤其如此)必须极其谨慎，因为程序员编写C语言代码时若忘记这些防范措施，写shell脚本时就更不会费心去做了。
记得2001-2002年间，几乎所有二进制程序都被发现存在此类漏洞的变种。当时我恰好负责管理一批规模庞大、备受关注的Linux服务器集群。真是段“美好时光”啊。
> 如今显然大家都知道这点，希望不会再用可预测的文件名，但这确实是一种手段。
恼人的副作用：现在你得猜是哪只进程创建了该死的锁定文件。
更明智的做法是对锁定文件及其内容进行合理性检查(即文件内PID是否与自身二进制程序匹配)。
> 现在你得猜是哪只进程创建了该死的锁定文件
或者直接用“lsof”命令查明。
另一个论点是：通过耗尽磁盘空间或inode资源，你实际上能对系统实施DoS攻击。
嗯——现在有了管理串行端口等设备访问的“lockdev”，但表达“该程序每次只能运行一个实例”的首选方法是什么？
我不确定 最优 方法是什么。但目前对我来说，对自身可执行文件加锁就够用了。
一如既往，Debian 搞定这事恐怕还得再耗十年。
考虑到我从未因系统臃肿或崩溃而重装过 Debian，我完全接受这种慢工出细活的策略。甚至支持他们在这方面的做法。
Gentoo Linux 的方法与 Debian 截然不同[0]，但经历最初一两个月(等我这个Linux菜鸟搞懂操作逻辑后)，我从未重装过任何 Gentoo 系统[1]。
若你追求 Debian 提供的特性，这确实不是理想选择… 但根据我的经验——它升级时不会崩溃，不像我过去尝试过的某些Debian衍生发行版那样。
[0] 核心理念类似于：“始终努力打包上游提供的精确版本，竭力将发行版补丁回馈上游，并在'测试通道'中提供最新可用上游版本。”
[1] 确实，我有一台机器(除了偶尔“侧载”内核更新外)四年未曾更新。虽然我会尝试按常规方式更新它，但 很可能 需要重装系统。
没错，慢工出细活正是我偏爱Debian的核心原因之一。
我不急。我喜欢稳定的东西。
准备就绪后自然会推送，这才是正确流程
相比之下，Debian的讨论让政治辩论都显得迅捷高效
> 他说自己“几乎时刻使用cu命令，通过USB连接与笔记本电脑上的嵌入式串行控制台交互”
为什幺呜呜呜呜呜呜呜呜呜呜呜呜
这有上百万种更优解法啊。
我用GNU screen搞定这事。看下 cu，它同样精简，还支持类似ssh的波浪号转义，包括用“~.”断开连接。不错，得试试看，谢啦！
我早年就习惯用minicom了。界面清爽，功能实用。
用了二十多年minicom后，我直到两年前才转用screen
固定配置场景下cu或许不错，否则我还是选minicom
你有什么推荐？个人认为在所有图形化串行终端程序中，cu的操作体验最接近ssh，且能在FreeBSD、Mac OS等Unix系统轻松获取，这点很加分。
cu才是常规做法
我看不出问题所在。相比cu，minicom甚至picocom都显得臃肿
某条评论[0]突显了当前实现方案的优势：
> 为每条拨入线路创建锁定文件，防止其被寻找拨出线路的程序占用。
[0]: https://lwn.net/Articles/1042594/