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
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
+++
title = "稻草人周刊 Vol. 55"
subtitle = "吵架的目的从来不是胜利"
tags = [
"自由软件",
"生物学",
"AI",
"效率",
"生活",
]
date = 2025-11-17T09:57:00
draft = false
toc = true
mentioned_books = [ "厌女",]
aliases = [ "/posts/weekly/55",]
+++
{{< music cover="https://img.eltr.ac/uPic/2025/11/Lorde_-_Virgin.png" title="Broken Glass" artist="Lorde" apple="https://music.apple.com/cn/album/broken-glass/1810905299" spotify="https://open.spotify.com/track/6xCKXznjcHv2hZWDA0pRIe" netease="https://music.163.com/#/song?id=2719794406" >}}
> I wanna punch the [mirror](/tags/M/), to make her see that this won't last.
>
> It might be months of bad luck.
>
> But what if it's just broken glass?
<!--more-->
---
## ⋈︎ · 连接
### 吵架的目的从来不是胜利
> [!note] 📻
> [277-如何成为全能吵架王？–独树不成林](https://podcasts.apple.com/cn/podcast/%E7%8B%AC%E6%A0%91%E4%B8%8D%E6%88%90%E6%9E%97/id1711052890?l=en-GB&i=1000736888214)
> 当你真的决定要跟人吵架的时候，你应该记得：你愿意跟人吵架意味着你还愿意继续跟他说下去，你不想把他从你的人生中删除。所以吵架是一种成年人的奢侈品。它预设了平等，它预设了这种**更高的善意**，它预设了未来可以继续对话的可能性。
这期播客听得我很爽，因为我感到有人终于帮我把我对争论和吵架的想法阐述清楚了。虽然我不像树老师那样喜欢吵架，但我认为争吵是有巨大价值的，并且是绝对不应该逃避的。我想起了我上周听的一起博客《[一场建设性吵架，是终结内耗的最佳途径](https://podcasts.apple.com/cn/podcast/%E5%87%BA%E9%80%83%E5%9C%A8%E5%8D%B3/id1533388375?l=en-GB&i=1000735125255)》，其中的主播之一就是曾经会在吵架中转移话题避免冲突的人，我听完之后直冒火，我极度厌恶那些让争论进行到一半，不直接表示想要退出，只是通过各种方式转移话题或者直接不理人的人；情绪缓和之后，我开始欣赏她改变自己对吵架想法并不继续逃避的做法。
树老师在这期播客中的先阐述了什么是「小学生吵架」，以及成年人之间的吵架应该是怎样的。她认为，小学生吵架主要通过比拼词汇量和道德模板进行——谁的污言秽语最多，最先让对方破防，谁就赢了；谁套用的道德模板最高级，能在所谓的道德制高点上碾压对手，谁就赢了。这些东西与吵架本身无关，只是小学生或还像小学生一样吵架的成年人们在吵架之前就已经学到过、吸收到、积累到的东西。她还认为，那些能共同过权力压制解决的问题本身就不能够通过语言解决，因为吵架预设了参与者之间是绝对平等的，正是因为这种平等才允许人们在智识层面进行切磋。吵架可以有情绪，并且绝对不能上头，不应该翻旧账，不应该人身攻击（如果对方说的话真的让你对他这个人感到鄙夷，那么令你鄙夷的人是不值得与之争吵的）。
其中最让印象深刻的观点是，当你在吵架的过程中感到了侮辱，或者感到对方没有预设吵架应有的平等，那么你为什么要在乎这个不会吵架的人嘴里吐出来的话？更重要的是，你为什么还要继续和这种人吵？吵架意味着你希望这个人继续留在你的生命里，如果你把这个人从你的生活中降级为零，那他说的话对你而言就毫无价值。
不过，我也要反思，我似乎也没能避免关注吵架的输赢这件事情，但我想这是因为我十分在意吵架要有个结尾这件事：任何一方诚实地提出自己不想继续参与争执，这是一个结尾；两个人各自保留部分观点，并得出了一个两人都满意的结论，这是一个很好的结尾；一人被说服，承认对方的观点是正确的，这个结尾也同样好；两人各执己见，最后表示今后应当避免谈论此类问题，这个结尾不太好，但很合理，也算结尾。而在争吵的中途擅自离开，仅因为自己受不了争吵，还不直接承认自己不想争吵这个事实，只留下对方一个人还在先前的观点纠葛和情绪中，是非常令人火大的——逃避问题不会解决问题，认为问题不需要解决就是对关系的不负责。目前我对那些逃避争执的人的做法是：远离他们，将他们从我的生活中降级。
我想我对这种人有种失落感，因为我之所以愿意跟他们进行观点的争论，就是因为我原本以为他们是可以交心的朋友，毕竟吵架意味着在乎彼此，逃避吵架不仅仅是逃避了关系本身，还表达了「我不在乎你这个人的存在」这一层含义——这可能不是对方的直接目的，但行为的确反应了这一点。
### FFmpeg 对 Google：捐钱，不然别给我们送 Bug 了
> [!note] 📜
> [FFmpeg to Google: Fund Us or Stop Sending Bugs - The New Stack](https://thenewstack.io/ffmpeg-to-google-fund-us-or-stop-sending-bugs/)
FFmpeg 是一个非常重要的开源软件库，它用于转换音频和视频，包括 YouTube 在内的许多网站和软件都使用了 FFmpeg 提供的库。和许多其他的开源库一样，FFmpeg 面临资助不足的问题。这个开源库几乎完全是志愿者维护的，大家是把这件事情当作爱好进行免费劳动，开源软件几乎都是这样的。然而，近期 FFmpeg 却和 Google 闹了矛盾。
简单来说，Google 使用他们的 AI 机器人不断地向 FFmpeg 发送 bug 反馈，要求维护者修复潜在的安全问题。安全风险当然重要，FFmpeg 也声称他们非常注重软件的安全性，但问题在于，Google 发送报告的速度太快，已经给这些维护软件的爱好者带来了压力，而且，大部分所谓的潜在安全问题，实际上并没有那么紧急需要修复。更何况，FFmpeg 是用 C 语言和汇编语言编写的，汇编程序维护起来有多困难不必多言，大部分的这些问题其实不值得汇编程序员花那么多的时间。在很多人看来 Google 用 AI 找 Bug 给这些爱好者增加工作量的做法无疑是在耍流氓，但有人声称：反馈问题也是对开源软件的一种贡献！真的是很流氓了。
在之前，libxml2，同样是一个基础但重要的开源软件库，维护者因为每周需要在这个没有金钱回报的项目上花费太多时间精力而退出了工作。很难想象，如果我们继续这样对待开源库的维护者，包括大公司在内依赖的底层软件库可能都不会有人维护了。
### XLST RIP
> [!note] 📜
> [Removing XSLT for a more secure browser \| Web Platform \| Chrome for Developers](https://developer.chrome.com/docs/web-platform/deprecating-xslt)
> [!note] 📜
> [XSLT.RIP - Google are killing XSLT!](https://xslt.rip/)
Google 即将在 Chromium 中移除 XSLT（将 XML 转换为其他格式显示的技术，被用在许多政府网站和一些 RSS 订阅源中），相关代码将在 2026 年 11 月完全废除，他们称此举是为了创造一个「更安全的浏览器」，并且 Mozilla 和 Apple 也将跟随 Google 的决定——很恐怖，Google 的一个决定就可以改变全世界的 Web 体验！Google 这边的说法是：
> The continued inclusion of XSLT 1.0 in web browsers presents a significant and unnecessary security risk. The underlying libraries that process these transformations, such as libxslt (used by Chromium browsers), are complex, aging C/C++ codebases. This type of code is notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution. For example, security audits and bug trackers have repeatedly identified high-severity vulnerabilities in these parsers (e.g., CVE-2025-7425 and CVE-2022-22834, both in libxslt). Because client-side XSLT is now a niche, rarely-used feature, these libraries receive far less maintenance and security scrutiny than core JavaScript engines, yet they represent a direct, potent attack surface for processing untrusted web content. Indeed, XSLT is the source of several recent high-profile security exploits that continue to put browser users at risk. The security risks of maintaining this brittle, legacy functionality far outweighs its limited modern utility.
大意是，XSLT 的底层库已经很老了，是很复杂、维护起来很困难且有很多安全风险的 C/C++ 代码库，这类代码往往有缓冲区溢出的问题，可能会被利用执行恶意代码。又考虑到，XSLT 在目前的 Web 环境中已经很少使用了，更现代的做法是使用 JSON 而不是 XML，也不会直接转换数据文件本身，通常会用获取并解析 JSON 数据的方式通过 JavaScript 展示。这么看，其实移除老旧，还有安全风险的技术而不是重写，是比较方便的做法。
另一边，XLST RIP 这个网站的作者声称，自 Google 移除 RSS 阅读器 Google Reader 以来，他们又杀死了近 300 项技术，几乎可以肯定 Google 厌恶 XML 和 RSS。作者呼吁所有人在自己的网站上添加 XSLT，不要让 Google 轻易地又杀死一项技术。这个网站的作者认为，目前还没有 XLST 用户被黑的案例，Google 说什么安全风险是在把用户当猴耍。
我的 [RSS 源](/index.xml)也使用了 XLST，我是不希望这个技术消失的。并且，浏览器明显应该尽量向下兼容。在我看来，Google 不一定邪恶，但在某种程度上可以说他们很懒，因为他们完全可以把实现 XLST 的底层库用更安全的方式重写一遍，比如用自家的 Go 语言——不过指望他们这么做大概是不可能的，毕竟[他们一直给开源库反馈 Bug 却从没想过捐钱或者自己修](https://thenewstack.io/ffmpeg-to-google-fund-us-or-stop-sending-bugs/)。
### 适宜的大小
> [!note] 📜
> [On Being the Right Size by J. B. S. Haldane 1928](https://www.marxists.org/archive/haldane/works/1920s/right-size.htm)
人们时常想象巨人的出现，[生物学家 J. B. S. Haldane](https://zh.wikipedia.org/wiki/%E7%BA%A6%E7%BF%B0%C2%B7%E4%BC%AF%E9%A1%BF%C2%B7%E6%A1%91%E5%BE%B7%E6%A3%AE%C2%B7%E9%9C%8D%E5%B0%94%E4%B8%B9)在文中表达了这样的观点：一个生物不可能只改变大小，而不改变形态和结构。他举例说，假使一个羚羊变得更大，它要么像河马一样长出更粗壮的四肢来支撑重量，要么像长颈鹿一样将四肢展开、倾斜。变大意味着重量会快速增长，如果结构和形态不变，骨头就没办法支撑，轻微的移动都会导致骨折。此外，如果变大，生物也需要更粗壮的血管，因为需要更大的血压来降血液输送到全身；呼吸也是一样；还有对食物和热量的需求，仅仅是长大十倍，就意味着机体需要摄入一千倍的热量。体型巨大的生物受重力的影响更大，相比之下，小老鼠和蚊子就受重力的影响就很小，不过，蚊虫受表面张力的影响很大，这也是为什么人类在沐浴之后即使身上附着了几斤水也没事，但虫子被浸湿了却是要命的。
总的来说，每一种动物都有他们的最佳尺寸。同样的道理也可以推广到人类组织，对于一个团体、组织、政党或企业，扩大规模意味着机制、结构和运作模式也要发生改变，规模越大也意味着复杂度越高。就像动物只变大而不进化出更复杂的结构会是致命的，人类组织要是只增长而不调整，也会出问题。
### 记忆系统的一种用法
> [!note] 📜
> [How I use memory systems](https://michaelnotebook.com/ongoing/hiums.html)
作者是一个物理学和计算机领域的研究员（Research Fellow），这篇文章里他介绍了他使用 Anki 等记忆系统的方法。顺带一提，这篇文章是博客文章《[阅读的目的从来不是获取知识](/posts/阅读的目的从来不是获取知识/)》下 [@pepperex](https://github.com/pepperex) 推荐给我的。
作者会把自己在视频、电影和影视剧里看到的，给他带来极大情感触动的画面做成记忆卡片，放在 Anki 里，目的是为了让自己时常回忆、重新思考这些由视觉信息触发的感受。这种做法对我而言很新奇。作者把 Anki 当作一个「创造意义的语境」，他会写在卡片里的东西并不是「我觉得自己应该感兴趣、应该记住的东西」，而是他真正感兴趣，但因为对相关知识的理解还不够深入，所以不能够阐明意义、理解透彻的东西。把这样的东西写成记忆卡片，每天回顾，能帮助自己思考和建立新的理解。
> Anki is especially helpful in areas which you are very interested in, but don't yet have the expertise to enable rapid encoding of new memories.
>
> Anki 在那些你感兴趣，但并不具有能够快速编码新记忆的专业能力的领域，尤其有用。
作者还引用了美国作家 Edwim Schlossberg 的话：
> The skill of writing is creating a context in which people can think.
>
> 写作的技巧在于创造允许人们思考的语境。
更重要的是，作者认为，要创造作者自己能够思考的语境。如果做得好，产生新想法就会变得简单。对他来说，写 Anki 卡片就是能够创造这种语境的写作方式。
作者提出的这种方法似乎对初入一个新领域的学习者十分有用，正好我最近也在学些新东西，确实也可以写一些卡片来巩固记忆和加深理解。
### 美国的书籍审核
> [!note] 📻
> [276-美国出版界如何审核书籍？ - 独树不成林](https://podcasts.apple.com/cn/podcast/%E7%8B%AC%E6%A0%91%E4%B8%8D%E6%88%90%E6%9E%97/id1711052890?i=1000736525089)
仲树老师描述了美国出版界的现状。传统上讲，在美国出版书籍需要经过同行审核（peer review），这导致的问题是那些挑战领域内传统观点的书籍很可能得不到出版。如今，在美国出版不仅有同行审核这个障碍，还有政治正确这个障碍。出版社会雇佣「敏感审查员」，帮助作者和图书编辑把书本内容变得不那么「敏感」，防止书籍在出版的最后阶段被取消，或者在发布之后被群情激愤的读者「取消」。这些敏感审查员不需要任何资历，只需要属于某一群体，比如，一本描写了黑人生活的书，就要交给一个黑人敏感审查员审查，他们会关注「这个黑人晚餐吃了什么」这种无关紧要但不知为何十分敏感的细节。
诚然，敏感审查员对一本书的文学和思想价值毫无帮助，在美国出版界却是必不可少的。树老师认为敏感审查的做法无疑是加重了群体之间的矛盾，规定「黑人只能吃某种晚餐」「黑人只能说饶舌俚语」本就是在加深刻板印象、加剧种族歧视。
社交媒体上如 Cancel Culture 这样的风气如今也开始影响传统纸质媒体和书籍出版了，这很可怕，而且在中国（中文是除了英文之外受众最多的出版语言），这种趋势也有苗头。
## ⁂ · 星群
### AI 世界时钟
作者让不同的模型每分钟用 HTML 和 CSS 生成一个带动画的时钟，做成了一个网站。我不清楚作者开发这个项目的目的是什么，但我极度怀疑他是为了展示 LLM 的平面想象能力有多么弱智。
{{< gallery >}}
{{</ gallery >}}
目前看来，只有 Kimi K2 生成的时钟质量比较稳定，至少是为数不多能用的。
访问：[AI World Clocks](https://clocks.brianmoore.com/)
## ↯ · 当下
### 开发 wthis
我对自己的设备有种奇怪的洁癖，会不定期浏览电脑上安装的 App 并卸载长时间未使用的，即使这个程序不会占用太多的存储空间。某天，我把目光转向了 macOS 上的命令行工具，运行 `brew list` 发现 Homebrew 列出来的大部分软件包我都不认识，用 `brew info` 查询的结果可读性极差，遂用 Go 写了一个[命令行工具](https://github.com/BigCoke233/wthis)。
看到不认识的 Formula 就大喊「What the ~~Heck~~Homebrew is this?」，即可获取必要信息：
```shell
wthis <formula_cask_name>
```
个人认为最有用的是可以直观地看到这个包是自己运行 `brew install` 安装的还是作为依赖自动安装的，如果是作为依赖安装的，则会列出依赖于这个包的其他包。同时还会查询对应二进制文件上次被访问的时间，也就是可以看到自己最近有没有用过这个软件。我把这两个部分的信息称作「用户交互记录」，这么看的话就会很清楚某个软件包为什么出现在列表里，以及应不应该留下。
如果你感兴趣，可以运行一下命令安装 wthis。
```shell
brew install BigCoke233/tap/wthis
```
开发过程很有趣，第一次写 CLI，控制换行和排版什么的没有想象的那么简单；学到了一些 Homebrew 相关的基础概念。写 Hugo 主题的时候也会用到一些嵌入的 Go 语言代码，但整体写的不多，所以在做这个程序的时候也难免求助 ChatGPT。从敲代码的体感上，Go 很像是现代化、更花哨也更好用的 C 语言，虽然结构体和指针一个不少，但写起来还算方便（但是 Go 移除了三目表达式，这个还是非常不习惯的！）。做完 `v0.1.0` 版本之后就去看 Go 语言文档查漏补缺，今年年初为了做游戏学了 Lua，那今年就以入门 Go 作为结尾吧——总觉得这两门语言在气质上有些类似，尽管一个是脚本语言，一个是更底层的语言。
访问：[GitHub - BigCoke233/wthis](https://github.com/BigCoke233/wthis)
### 学习 Go 语言如何助长我的语言偏见？
这 Go 语言越学，我就越讨厌 Java 这门语言。无意冒犯 Java 开发者，但我愈发觉得，人们使用 Java 的最大原因并非是这门语言和它的技术栈有多好用，而是因为技术债务[^1]、传统、人力资源[^2]和让人产生依赖的软件生态。事实上，选用其他编程语言和技术栈照样可以写出健壮、功能完善的后端程序，性能、速度和安全性可能还更好。
我承认我对 Java 有偏见，我的确不喜欢这门语言，从刚接触到这一门语言和热门的 Spring 框架起，我就疑惑为什么实现简单的需求需要编写这么多文件和类、为什么有这么多的抽象、为什么有这么多我不清楚原理的「魔法」。即使弃用了 IDEA，转用一个简单的编辑器和命令行进行开发，做到了尽量透明可控，我依然对这门臃肿、啰嗦、复杂的语言提不起好感。
诚然，我接触 Go 的时候也感到不适应，也会产生疑惑：为什么要移除这么好用的三目表达式？为什么编译器这么严格，未被使用的引用居然会导致编译时报错？为什么没有传统面向对象编程的类和继承？不过很快这些疑问就得到了解答，我很快就爱上了这门语言以及它背后的各种编程哲学。我正在逐条学习 [Go Proverbs](https://go-proverbs.github.io/)，目前为止我最喜欢的一条是：
> Clear is better than clever.
>
> 聪明比不过清晰。
### 本周看了什么？
《地狱客栈》（Hazbin Hotel）第二季更新到第六集了，这个剧情走向越来越让我感到迷惑。本来以为在铺垫，但是这季总共也就八集啊…… 我认为问题可能在于剧情线太多了，每个（组）人物都需要占用时间铺垫和表现，以至于第二季的叙事在我看来有些慌张，人物的动机和行为都挺令人费解的。如果每集时间更长或者剧集数更多的话，或许观感会有提升。
目前最喜欢的音乐片段来自我最喜欢的角色 Husk（谁会不喜欢酒保猫恶魔！）。
<iframe src="//player.bilibili.com/player.html?isOutside=true&aid=115541331148948&bvid=BV1vGC4B3ETf&cid=33969997588&p=1&autoplay=0" scrolling="no" border="0" frameborder="no" framespacing="0" allowfullscreen="true" loading="lazy" width="100%" height="400px"></iframe>
周五看了有名的音乐剧《吉屋出租》（Rent），看到四分之一的样子就没看了。我得说我不太能欣赏得来，叙事和音乐在我看来都有些乱乱的，兴许过几年再看会能够理解吧。
周六看了 Apple TV 的新剧《同乐者》（Pluribus），很喜欢。这应该是今年看的第二部来自 Apple 的美剧了，第一部是《人生切割术》的前两季。目前的印象是，Apple TV 的剧集质量都还不错。《同乐者》是科幻题材的乌托邦（或反乌托邦）美剧，除了主角和少数幸存者，地球上所有人类都成为了一个集体意识，这让我想到了《瑞克与莫蒂》里的 Unity。不幸的是，尽管集体意识能够满足主角的所有需求，甚至带她找到其他的还保有自我意识的个体，她依然感到孤独和不快乐。目前《同乐者》只推出了三集，这三集我都很喜欢，期待后续。
2025 年年底真的有很多好东西，本人的文娱生活算是有救了。尽管还没定档，但今年年底应该会上线音乐剧《魔法坏女巫》的第二部分，美剧《怪奇物语》也会在今年年底和明年年初播出。
### 今年第一次去酒吧
本人患有癫痫，不能饮酒，所以基本不去酒吧。上次去酒吧已经是去年的事情了，那个时候喝的是可乐；周日晚上被朋友叫去了酒吧玩，喝的是椰奶。酒吧不是夜店那种氛围，有点像夜间版的咖啡馆。我们都没怎么喝酒，只是在聊天和玩游戏。不过朋友叫了三个来自中东国家的外国友人（他们穆斯林似乎也不喝酒），全场没有一个人的母语是英语但不得不用英语交流，再加上拉人的这个朋友自己还喝醉了，玩游戏的时候语言功能至少丧失了 50%…… 总之整个局的氛围挺奇妙。
大家离开的时候明显没有特别开心，我觉得我可以从一个旁观者的视角分析一下原因，还挺有意思的：
三个穆斯林小哥是兄弟，一开始只来了一个，在场大部分都是女性的时候他的行为和他的兄弟来了之后的行为明显不一样。一开始他会拿牌玩魔术逗人开心，行为很有分寸，等另外两个人来了之后他就和他们一起讲荤段子了，甚至连笑声和笑容都变了——和我同行的基本上都是女性，他们对这种玩笑感到不舒服。我觉得最令人不适的一个玩笑是：玩游戏的时候我们让他们猜同行的一位女生喜欢男性还是女性，他伸出两根手指让女生选一根，然后因为女生选了更长的那根就说她喜欢男的……
在我的观察里，这是一种很常见的同伴压力，或者用上野千鹤子在《[厌女](/library/2024/厌女/)》中提到的「男性同性社会同盟」——当男性聚集在一起时，他们会避免被其他男性认为「不是真男人」。他们在开男同玩笑的时候，还说「Real men fuck real men.[^3]」这种话。
我其实不觉得这三位男性有多坏，我只觉得这是普通直男在同性群体里常有的表现，尽管我表示鄙夷。
[^1]: 技术债务（technical debt）指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。—— 来源：[技术负债 - 维基百科](https://zh.wikipedia.org/wiki/%E6%8A%80%E6%9C%AF%E8%B4%9F%E5%80%BA)
[^2]: 学过 Java 的人一定比学 Go 或其他语言的多，除了 C 语言、C++、Python 和 JavaScript 这些一般不会用在 Web 后端开发的语言。不过现在用 Node.js 写后端也很常见了。
[^3]: 真男人才操真男人。
|
