blob: 977c04b5384d2fdf1f442873d63e967734de598a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
+++
title = "大脑充血 Vol.85"
subtitle = ""
tags = []
date = 2026-06-08T14:37:56+08:00
draft = true
toc = true
+++
《稻草人周刊》更名为《大脑充血》，不过内容的变动不大，还是继承以前的编号。名字的灵感来源于我很喜欢的一张塔罗牌「[倒吊人](/article/tarot-hanged-man/)」。
<!--more-->
---
## 止语
{{< music cover="" title="" artist="" apple="" spotify="" netease="" >}}
---
## 连接
### 如何嬉皮笑脸地应对「为你好」的人
> [!note] 📻
> [《独树不成林》344 - 如何嘻皮笑脸地应对打着我为你好的旗号来管管你的家人？](https://www.xiaoyuzhoufm.com/episode/6a2a16463eedf1f4b268c4cd)
树老师认为她能保持心力的很大原因是，她面对打着「为你好」旗号来管她的人能够做到**不上心**。这种人无处不在，甚至与权力结构和社会地位无关，不只有上位者管理下位者，平辈和下位者也可能以各种理由管别人——这是一种**人格缺陷**。跟这些具有人格缺陷的人讲道理是没用的，在某些极端案例中，这些人根本不讲道理，仅仅是想在你的生活里找点存在感。树老师说她奶奶会给她和她的表妹完全相反的人生建议，仅仅是为了「管管他们」。某种程度上，这些人是在给不存在的公众表演，这种公众在落后的社会中可能存在，但在现代的、原子化的社会中，表演美德没有意义。很多人逃不掉这种思想钢印，总是在表演，「管管你」就是一种表演，对长辈来说，这是尽到教育责任的表演（尽管他们根本不懂教育，仅仅是自以为是而已）；对另外的人来说，这也是某种把自己塑造成热心的好人的表演。
我想补充的观点是，这种人格缺陷有大有小，也可能以不那么明显的症状出现在年轻人身上。有较轻「症状」的人可能也会抱怨「为你好」的管教，而意识不到自己也在做一样的事情。仔细想想的话，那些试图把「正确方式」教给你的人无处不在，比如使用某个编辑器的正确方式、查阅资料的正确方式、做笔记的正确方式、软件架构的正确实践等等。这些建议往往都忽略了特异性，人与人之间特质和需求的差异，不同情况下对解决方案的不同要求。可笑的是，如果反对他们的意见，他们可能会觉得是你「不懂做笔记」「没有把笔记当作笔记来对待」。他们为什么跨越社交边界去管这些琐碎的小事？我认为和「为你好」的长辈一样，都是人格缺陷，只是表现和轻重有别。
这些观点当然是有意义的，对个体和一部分群体来说可能很好，但硬塞给别人无异于精神强奸。甚者，可能发展成邪教：*这个东西这么好！我们都这样用！你为什么不用？！你必须要这样用，因为……* 这些东西写在你自己的博客里就行了。
我最近的确被太多这样的人困扰了，一方面是来自学校，关于老师的各种可笑行径和言论我已经在联邦宇宙上写了太多了，再写只会消磨自己的心力，这里就不再赘述了；另外还有来自现实及网络上各种琐碎的社交，某些强硬的观点也让我喘不过气，甚至让我对原本很感兴趣的事物都产生了厌恶情绪。我不清楚这是不是我的人格缺陷，我对所有事情都很容易上心。我在《[这个世界会累死完美主义者吗？](/posts/exhausted-perfectionist/)》里讨论过这一特质给我带来的困扰。我一直想要快点毕业，找到工作，去到我自己选择的城市，远离我讨厌的人（一两年前，我甚至想要[远离这个国家](/posts/Fly-Me-To-The-Moon/)）。
不过就像树老师在播客里说的，无论逃到哪里都无法远离这种人，*他们无处不在*。
我在阅读以前的文章时，发现自己当下的困扰与一两年前的困扰惊人地相似：
> 我要是这么写下去，你大概会觉得可笑吧，看着这个本科生像小孩子一样抱怨自己的老师…… 我也觉得自己可笑，明明把自己的生活安排得好好的，只因为台上那个自我感觉良好的男人能对自己指指点点，心情就一落千丈。
>
> 但我实在难以接受，自己每周要被他浪费 270 分钟的宝贵时间，听他用 20 分钟解释我 5 分钟能理解的概念，然后听他时不时爹味爆发，教我们要怎样过好自己的生活，还发表一下自己对于哪些人应该拿毕业证、哪些人就不该发毕业证的看法，全是不着边际的空谈，没有任何实在的方法和新颖独到的思想。我每次听他讲课，心里都在呐喊：你能不能不要再浪费我的时间了！
{{< right "——《[Fly Me to The Moon](/posts/Fly-Me-To-The-Moon/)》" >}}
我一直，都无法停下在乎蠢货说的话，我恨，那些蛮不讲理、学识浅薄、过度自信的人，能肆无忌惮地浪费我的时间和摆弄我的自由，而我什么也做不了。我一直都学不会屏蔽他们的话，因为，如果我作为人类，和自己存在的环境完全解离，那会是多么可怕的事情！而且，我向来讨厌说谎，我不喜欢说违心的话，只为了让那些蠢货能离我远点。
我的策略一直是远离，远离那些完全无法沟通或者我不愿意费心费力沟通的人，但我想我该开始接受身不由己的事实，在公众面前、在*老登*面前，应该撒谎、应该表演、应该解离，以便获得内心的安宁。
---
## 茶歇
### NPM 的安全更新
> [!note] 📃
> [Upcoming breaking changes for npm v12](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/)
NPM 即将在七月份发布 `v12` 版本，主要有三项改动，均涉及 `npm install` 命令：
1. 默认禁用脚本，安装前、安装时和安装后，依赖都不能执行脚本，除非手动允许
2. 默认禁止从 Git 仓库解析依赖，无论是直接还是间接的依赖，出否手动运行
3. 默认禁止从远程 URL 解析依赖，除非手动允许
更多技术细节可以阅读[原文](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/)。安装前后执行的脚本、从 Git 仓库和远程 URL 下载的外部代码，都是很多 NPM 供应链攻击的来源。之前我在[第 83 期周刊](/weekly/83/#用-pnpm-规避供应链攻击)分享了如何用 PNPM 规避供应链攻击，其中提到的策略也几乎一致。
不过这仅仅是客户端层面的防控措施，为什么 NPM 不能想办法加强中心包索引的安全性呢？哦等等…… 我在 Hacker News 的讨论区发现了什么？——[NPM 在 2020 年加入了 GitHub](https://github.blog/news-insights/company-news/npm-is-joining-github/)？原来也是微软的一部分，那不稀奇了。
我怎么感觉 JavaScript 生态不会好起来了？
### Homebrew 6.0.0 发布
> [!note] 🍺
> [Homebrew: 6.0.0](https://brew.sh/2026/06/11/homebrew-6.0.0/)
macOS 事实意义上的默认包管理器发布大版本更新，主要变化有两个，一是新增了 Tap 的信任策略，在未受信任之前，Tap 里的代码无法运行，避免执行恶意程序。*看起来大家都终于开始在意软件包安全性了。*
另一个变化是 Homebrew 的 API，现在 `brew update` 运行更快了，因为 API 变小了，Homebrew 需要建立的网络连接也变少了。Homebrew 的性能在此之前一直都是个问题，我在[第 74 期周刊](/weekly/74/#nanobrew)推荐过 [nanobrew](https://nanobrew.trilok.ai/)，是用 Zig 写的第三方 Homebrew 客户端，据说速度快很多，不过我的实际体验是，速度并没有很快，有些时候甚至更慢，而且由于刚推出没多久，Bug 也不少。新的 Homebrew 体验上确实快了不少，不过本地的网络环境应该还是最大的瓶颈。
顺带一提，我其实一直没有下定决心折腾 Nix，我感觉它太重了，以及我也没有那么在乎「可复现性」。对我来说，只要管理好关键软件的 dotfiles 就好了，比方说 Neovim 配置和 Ghostty 配置等等。有不少我用的软件包没有 Homebrew Formulae，如果要在集中管理和轻量化之间取折中方案，我想可以自己维护一个私有的 Tap，写一些 Formulae 自己用。不过这就意味着我要学 Ruby 了。
### Chromium 或将无法使用 uBlock Origin
> [!note] 📃
> [Google Chrome is killing all uBlock Origin bypasses, Microsoft Edge, Opera to follow](https://www.neowin.net/news/google-chrome-is-killing-all-ublock-origin-bypasses-microsoft-edge-opera-to-follow/)
谷歌即将终止对 Manifest V2 的支持，广告、追踪器拦截插件 uBlock Origin 就依赖 MV2 提供的 API，一旦 MV2 不受支持，在 Chromium 上就只能使用基于 Manifest V3 的 uBlock Origin Lite（并不好用）。Microsoft Edge 很早就禁用了 uBO，Opera 表示会跟进，目前只有 Brave 表示会继续支持 uBO。
我一直在使用 [Helium](https://github.com/imputnet/helium) 浏览器，它也是基于 Chromium 的（准确来说是 [ungoogled-chromium](https://github.com/ungoogled-software/ungoogled-chromium)），所以我很关心去谷歌化的 Chromium 系浏览器这边状况如何。不久前，ungoogled-chromium 的 Issues 区有[相关的讨论](https://github.com/ungoogled-software/ungoogled-chromium/issues/662#issuecomment-4620528374)，维护者表示他们还没有升级到 Chrome 151（也就是 MV2 被彻底禁用的版本）。之后的讨论…… 看起来很激烈，其中一位贡献者的[长篇大论](https://github.com/ungoogled-software/ungoogled-chromium/issues/662#issuecomment-4657975560)中甚至提及了要给浏览器添加在 Chrome Web Store 以外的地方安装浏览器拓展的能力。还有很多讨论是关于 uBO Lite 究竟好不好用的，ungoogled-chromium 如何继续支持 MV2 这个问题，我没有找到答案。
Helium 这边，从 README 来看，尽管基于 ungoogled-chromium，他们仍然做了很多修改。在发现了一条*过于幼稚导致我厌人症又发作的*相关 [Issue](https://github.com/imputnet/helium/issues/1169) 之后，我终于找到了主要维护者 [wukko](https://github.com/imputnet/helium/issues/1568#issuecomment-4365771817) 的答复——一位用户请求 Helium 从 [Supermium](https://github.com/win32ss/supermium) 合并补丁，以此持续 MV2 支持，wukko 的回复是：Helium 已经支持 MV2 并且自带 uBO 作为浏览器组件。看起来 Helium 用户不必担心 uBO 问题。
至于为什么不用 Firefox，可以阅读[第 18 期周刊](/weekly/18/#firefox-放弃了用户隐私)（不过那是一年前的消息了，如今可能有变化，但整体而言不太信任 Mozilla）。如果非要用，可以试试 [Waterfox](https://www.waterfox.com/) 或者 [LibreWolf](https://librewolf.net/)。不过，我不愿意使用 Firefox 系浏览器的主要原因是他对某些新 Web API 和 CSS 特性的支持实在太慢了——比方说，截止 2026 年 6 月 10 日，主流浏览器中只有 Firefox 没支持 [View Transition](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API#browser_compatibility)。
### 为 YAML 辩护
> [!note] 📜
> [In defense of YAML](https://opensource.posit.co/blog/2026-05-21_in-defense-of-yaml/)
文章简单介绍了配置文件格式的历史，从一开始不规范且扁平的 INI 文件，再到能够表达层级但过于臃肿的 XML，之后是适合数据交换但对人类编辑不够友好的 JSON，最终是这篇文章的主角——YAML 和 TOML。
顺带一提，我永远不会错过批评 Java 的机会：
> Anyone who maintained a Java web.xml or an Ant build file in 2003 knows what it was like to edit dozens of nested elements just to change a database connection string. The verbosity made the files difficult to maintain by hand, which is precisely what configuration files demand.
>
> 任何在 2003 年维护过 Java web.xml 或者 Ant 构建文件的人都知道，编辑一大堆嵌套的元素，只为了修改数据库连接字符串是什么样的。文件冗长使其很难徒手维护，而这恰恰是配置文件需要的。
如今 Spring Boot 简化了很多配置，但 Java 生态依旧使用 XML 格式，还有另一个令人闻风丧胆的 `properties` 文件，可以说是完美融合了 YAML 和 TOML 两边的**缺点**。
关于 YAML 和 TOML，主流的论调是：TOML 比 YAML 更好，而喜欢用 YAML 的人大多都是不了解情况（uninformed）。YAML 的语法难以预测，比方说 `no` 可能是挪威的国家代码，但会被 YAML 解析为 `false` 布尔值，`off`、`NO` 等其他字符串也是。问题在于 YAML 的隐式类型转换，有无 `""` 都会被视作字符串，大家都习惯不打引号了，而 TOML 必须显式地使用引号才会被解析为字符串。
此外 TOML 还致力于成为标准化的 INI，两者的语法类似，TOML 胜在能用方括号表示层级。尽管语法符合直觉，解析器也很容易实现，但对于深层次的数据结构，TOML 的表现力不如 YAML。如果嵌套较多、列表结构较多，TOML 就会变得很难读。TOML 也因此遭到了批评：
> TOML is a bad file format. It looks good at first glance, and for really really trivial things it is probably good. But once I started using it and the configuration schema became more complex, I found the syntax ugly and hard to read.
>
> TOML 是糟糕的文件格式。刚开始看起来很好，对非常、非常简单的事情或许也很好。但一旦我开始使用，并且配置格式变得更复杂之后，我发现语法变得很丑并且很难阅读。
{{< right "——[Martin Vejnár](https://github.com/avakar/pytoml/issues/15#issuecomment-217739462)" >}}
作者在文章最后指出，YAML 1.2 规范解决了以挪威代码为代表的问题，`no`、`yes` 等词不会被解析为布尔值了，只有 `true` 和 `false` 才会。六十进位数被移除了（所以 `22:22` 等端口配置不会出错），时间戳不再是核心类型（`2026-05-05` 会被解析为字符串，而不是自动解析的日期），JSON 是 YAML 的子集了，任何 JSON 文档都可以被 YAML 解析器解析（尽管我想不到这有什么用）。人们认知中问题百出的 YAML 是 1.1 版本，而 1.2 版本已经没有这个问题了。
不过我还是觉得，字符串应该被 `""` 包裹，不应该依赖隐式转换。
支持 YAML 1.2 的解析器较少，所以作者介绍了 [py-yaml12](https://github.com/posit-dev/py-yaml12)，这是用 Rust 写的 Python 库……？
据说是为了与 PyYAML 竞争，这个库是用 C 写的（也有 Python 的实现作为回落方案）。在性能上，由于 py-yaml12 使用编译好的 Rust 程序而不需要解释 Python 程序，性能可以与 PyYAML 竞争，同时它还支持 YAML 1.2，也是目前很难找到替代品的优势。
我的态度是，简单（尤其是层次较浅）的配置文件用 TOML，如果有复杂的配置要求，可以考虑 YAML 1.2。不过，如果配置文件真的足够复杂，用 JavaScript 或者 Lua 等脚本语言作为配置语言，貌似也不错？
---
## 星群
### clj.rs
用 Rust 实现的 Clojure 方言。
---
## 切片
- 六月九日
- 对人类感到厌倦，不想和任何人讨论任何事情，一鼓作气，在 uBlock Origin 里拦截了我的联邦宇宙实例和 Matrix 服务器，先让自己清静一段时间再说。以后有什么要发的，就先写在周刊里好了。
- 看了《Rick and Morty》第九季第三集…… 编剧你写的什么玩意儿？——*令人意外，但这并不是批评，我也不知道这是什么。*
- 七八点的时候突然想吃点东西，看到有卖墨西哥卷饼（大概就是传说中的 Taco 吧）的店，挑选了半天才发现单点不送，再加了一份薯条也不行，必须要我点两个饼。这是什么道理？！
故点了一份披萨，~~从热量来说都不相上下呢。~~
- 觉得 LLM 生成的内容很有道理并从未想过反驳，是否可以理解为「此人的认知水平在人类平均水准以下」？
- 六月十日
- 观点这种东西在博客里露露鸟就好了，在没有要求的情况下硬塞给别人，就像发屌照一样。由于心智和肉体的差别，精神上的发屌照和精神强奸区别不大。
- 结束糟糕的一天之后的发泄方式：在饥荒里带着一只熊獾把一片森林砍到只剩光秃秃的一小半。
堂堂秋季 Boss，从来没有被我亲自拿下过，每年都把它拉到森林里好一阵狂砍，接下来就是树精守卫和蜘蛛女王的事情了…… 月后等他变异成装甲熊獾之后还能看他反杀，再捡一地的活木和蜘蛛丝。
- 六月十一日
- 在 Go 语言里写 `if err != nil` 的时候我总是用法语把 `err` 读成 `/eʀ/`[^1] 而不是英语的 *error*，**直觉**上觉得 `err` 没有第二个元音，但有第二个字母 *r*，不能读成 *er* 也不能读成 *error*，于是就自然地读成法语了。就当作练习小舌音吧。
- [Hell yeah. Screw you, life, you watch me live the crap out of you.](https://redlib.privacyredirect.com/r/Existentialism/comments/fddnio/men_must_live_and_create_live_to_the_point_of/fjgxnof/?context=3#fjgxnof)
- 六月十二日
- 不用流媒体，所以不能第一时间听到 Olivia 的新专辑。发现她官网有售卖数字专辑，十美元，结果只能下载 MP3 格式，而且只开放给美国顾客下载…… 我除了 Piracy 还有别的选择吗？
## Footnotes
[^1]: 这是[国际音标](https://zh.wikipedia.org/wiki/%E5%9C%8B%E9%9A%9B%E9%9F%B3%E6%A8%99)，不要和国内常用的 DJ 音标（一直被误以为是国际音标，实则不然）搞混了。其中 `ʀ` 是小舌颤音。
|
