Journal 2025

说实话之前都没有听说过“cargo cult”。个人来说我对例如 master 和 main 之类的单语重命名倒是没有什么想法——“master”本身的词义也不少，无上下文的确无法评价（虽然我非常喜欢 main ）；但是，“cargo cult”的这种由假史料衍生出来的所谓“寓意”还是让人有些恶心，类似的自喻‘文明’的群体对‘非文明’甚至是动物的猎奇解读也是同理。

中文里对应“cargo cult”猎奇意的大概是“刻舟求剑”，也许好些？

《Luck be a Landlord》，中文译名一般是“幸运房东”，算是相对有名的一款独立游戏。它也启发了一些其它游戏，这类滚大数字卡牌构筑游戏有时候也被称为“幸运房东”游戏。总之， 就是摘一下 HN 的一个评论：

（大意）《幸运房东》被禁，《小丑牌》18+，而一众要真金实银的抽卡游戏却大行其道。 确实挺讽刺的。

– jsheard

这段时间其实在 Cloudflare 的后台也可以看到我的一些网站（包括这个博客）也在被各种扫。之前试着开了一下 Cloudflare 的防护，但结果是把 ActivityRelay 给屏蔽了。目前来看来是没什么误伤率比较低的方法。

在线面试时候的麦克风会对评价有影响。想起来之前看到过的交响乐团试音时即使让面试者在帷幕后进行演奏，高跟鞋也会踏出声音来，不能达成排除性别偏见的目的。查了一下倒没能查到相关文献……

讲的是恐音症（Misophonia）的事。我个人的话其实对咂吧嘴和音响外放也是差不多的感觉。 文档里提到的 Trapped Prior 听起来挺有道理的，毕竟我除了听觉外还有一些其它烦躁 trigger，例如抖腿（视觉）和味道大的食物/饮品（抱歉，这包括咖啡）。在我看来这些和公众场合外放都是差不多的行为。

之前吃饭的时候其实还是有概率因此而心烦气躁的，但是在有了降噪耳机之后其实好多了。

天哪……又是 W3C 把 ActivityPub 抛荒之后带来的一系列问题。本来最近因为折腾 Bluesky 自定义信息流的垃圾发文审核问题对 ActivityPub 稍有一点改观的，但是现在还是觉得这种 worse is better 的拍脑袋协议就放马桶里冲走吧。

HN Discussion: https://news.ycombinator.com/item?id=43559605

HN Discussion: https://news.ycombinator.com/item?id=43595269

把所有广告都禁掉，大开脑洞的一个想法。是不错的思想实验，但我个人比较悲观。

HN Discussion: https://news.ycombinator.com/item?id=43549893

总之就是 Ent 之前发表了一些政治敏感的话题，然后其大多中文网络上的痕迹就被消除掉了。最近想起来了 Ent 翻译/转载的部分短篇科幻，想找来看一下，于是下面的一大堆 Internet Archive链接就是其结果。

与其说是 Haskell 的介绍不如说是 STM (Software Transactional Memory) 的介绍。

在常见的 RDBMS 中，transaction 可以并行进行。在最严格的隔离度下：

• 一个 transaction 只能看见在其开始之前执行完毕的其它 transaction 的修改，而无法看见其它任何并行进行的 transaction 的改动。
• 在提交改动时，若当前 transaction 与其它 transaction 的改动冲突时，数据库会舍弃掉当前的修改，此时程序可选择重试修改。

STM 基本上就是把上述的数据隔离给推广到了近乎任意数据，只要声明为了 STM 数据，即可使用 transaction 对数据进行改动，从而避免了手动的锁操作及死锁等问题。（但我感觉这种是不是用个正经数据数据库会好些，而且性能也是个问题。）

又好久没更新过了。把一大堆之前看过的都放上来，当个书签吧：

• Speeding up Ruby by rewriting C… in Ruby: 基本上可以说是JIT 编译比 AOT 编译的优势
• CSS Minecraft: (HN) 9x9 Minecraft in Pure CSS & HTML… 太可怕了。所以我才觉得拿浏览器和老一辈的 GUI 框架来比都属于欺负人，你看这都是些什么怪物（褒义）。
• Why Hong Kong uses bamboo scaffolding, and meet the spider-men who climb it: a visual explainer: (HN of another similar post)
• WebGL Water

• Deep learning gets the glory, deep fact checking gets ignored

  用深度学习训练蛋白质分类，输出百来个“新”结果，然后只校验其中三个，最后发表在 Nature Communications 上。Wow…

  在我的领域这边，其实把人工智能用于分类的还不算太乱，最群魔乱舞的其实还是图像处理。对于现实的数据而言，很多时候是实际成像数据有不同程度的缺失，此时才有人工智能的用武之地——用各种其它数据来补全；但此时却恰恰没有可供校验的基准值，因此论证数据符合实际值的方法就还挺混乱的。

• Ask HN: Options for One-Handed Typing

  平时打字其实还挺 take for granted 的。另外，HN 评论区有挺多建议挺不错。跑去 QMK 上看了一下，发现它也有一个可用于单手输入的配置（Swap-Hands Action | QMK Firmware）。

把 bzip2 用 Rust 重写之后能有性能上的提升。注意这里的重写其实主要是用 c2rust 转换的，应该没有太大的改动，所以能有性能提升还是挺神奇的。HN 评论里猜测是 C 的语义不够明确，因此编译器没法进行某些优化；而 Rust 的 borrow checker 则明确了各种 aliasing 情况，因而 LLVM 可以大胆优化。

文章里的 benchmark 用了 CPU cycles 来表征两种 bzip 实现的性能，不知道 CPU cycles 和实际运行时间两种指标会有什么不同。

目前在写一个 Emacs Lisp JIT解释器（用的 Graal Truffle，因此也没什么技术含量）。 而说到动态语言的 JIT 运行时，那肯定是需要去参考下 V8 JavaScript 引擎的。

V8 里面的数组有着各种优化，例如 [1, 2, 3] 这类纯数字就可能会以“小整形”（SMI）的方式储存，而 [1, undefined, 2] 则有可能变为 holey SMI。 但无论如何，这些数据最底层的储存方式一定是数组，而不是什么见鬼的链表。

但很遗憾，Lisp 作为 LISt Processing 语言，它的最大的历史遗留问题之一就是——它的绝大多数数据结构/约定俗成都建立在了链表之上。我们不妨用数组来类比一下，看看 Lisp 的一系列操作在现在看来有多么离谱：

请注意上面所有操作都必须传递到所有/部分 subList 中去。

记录一下 AI 新闻。

今天在 HN 首页上看到了两篇吹嘘编程语言特性的文章：

• C3 solved memory lifetimes with scopes
• Zig’s New Async I/O

给我的感觉都是：作者为了吹捧自己的语言将其与其它语言对比，但却不愿意去了解其它语言与实际的问题，因而显得非常傲慢与无知。

第一篇的 C3 语言我是没有听说过，但是 memory lifetime 要是能这么简单解决的话那世上也不会有那么多 GC 语言了，这里也就不特地拿出来讲了。但是第二篇的 Zig 还算是个小有名气的新兴语言，吹嘘自己解决了其它语言的函数染色，就显得有些不妥……

让我们来看两个 Kotlin 的例子：

• 从异步函数里调用阻塞函数：使用 withContext 将任务放至别的线程执行，防止阻塞当前 event loop；
• 从阻塞函数中调用异步函数：使用 runBlocking 在当前线程中设置 event loop 并等待事件完成。

正如 HN 上评论说的，Zig 的 async 需要引入一个 IO 参数，而 IO 参数的有无本身就是一种染色。Zig 最多能做的也就是引入一些全局的 IO 变量，使得没有 IO 参数变量中的函数可以调用 IO 函数。但说到底，这也只是 Kotlin 上面两种方式的语法糖而已，倒也不是什么新东西。何况 Zig 甚至现在还没有完全实现基于 IO 参数的异步，这就使整篇吹嘘显得空谈且可笑。

写得挺好的，五味杂陈。

记录一些加沙新闻……哎

• The Gaza family torn apart by IDF snipers from Chicago and Munich

顺便一提，Itch 上也有募捐的 Bundle，感兴趣的可以看一下：Play for Peace - Games for Palestine 2025 Charity Bundle by Junch and 248 others。大致浏览了一下，听过名字的有 VVVVVV、篝火山峰（Bonfire Peaks）。Please buy :P

盲人开发者的实际体验。前段时间其实我有在找合适的 Rust 的 GUI 库，然后发现了 A 2025 Survey of Rust GUI Libraries (13 Apr 2025) 这篇文章。总结一下的话就是里面列举的大多数库根本没有屏幕阅读器的支持。只能说 A11Y (accessibility) 这方面还是道阻且长吧。（另外，虽然 GTK 在文章里面似乎说不支持，但是 (1) 它在 Linux 上是支持的而且 (2) 它在文章发布后的版本里用了（Rust 写的）AccessKit 把其它平台的支持也给加上了，还算有些希望。Qt？大概早支持了吧，和商业公司比不了跨平台支持啊……

科幻小说。前半部份讲 Manna，后半部分更像小灵通漫游未来，但说教感更强一些。

恶魔低语：修昔底德陷阱…… or whatever it might mean to you

Who’s that “we” here, huh? 上面抱怨过了 GUI 库的 A11Y 状况，那么这里说一下 TUI灾难的 BIDI 支持。BIDI 是什么呢？全称是 BIDIrectional text。在许多语言里，文字是从左到右书写的，但是有些文字——例如阿拉伯语——则是从右到左书写。要想让这些文字正确显示，那么就需要渲染软件/框架进行针对性的支持。

更进一步，上面一段文字我混用了中文和英文，而这两种语言的文字都正确显示了；但是， 如果有人混合使用了 R2L（right-to-left，从右到左）的文字和 L2R 的文字，那么要想让这整段的两种方向的文字正确显示，就会需要正确的 BIDI 支持。

说实话，现在的大多数终端啊什么的文字界面都是基于拉丁语系的。不说 BIDI，有时连中文都会有些问题，所以我的确没办法共情太多——怀旧挺好的，但是 TUI（无论是 30 年前的还是现在毫无改进的那些），我觉得还是埋在 30 年前的半宽字符世界就好。

Wayland… 我之前还写过一篇抱怨 Wayland 的文章来着……这篇文章其实和所有 Wayland 用户遇到的问题差不多——功能没有，做不到，或者就是有五百种实现需要你去兼容。

Lobsters 上有个评论讲了一下 xkb 和输入法相关的内容，我也在之前的博客里骂了。但我的的确确不知道现在有 input method v1, input method v2, text input v3, KDE fake input, virtual keyboard, text_inputv4… 都快二十年了，是真不把 IME 用户放在眼里啊……

想要找找 Qt 文本渲染的内部实现找到的一篇展示。整体对文本渲染过程的介绍不错，但没有太多实现细节……后面的说的 Qt 非直线文本渲染的确没听过，还挺厉害的。

最近在 HN 和 Lobsters 上看到了一大堆 Advent Calendar 相关的内容。最热门的当然是 Advent of Code，但其它也有 Advent of Compiler Optimisations 2025 和 Advent of Sysadmin 2025。然后我在翻 Lem 相关的内容来做参考，结果发现了 Lem Advent Calendar 2023，是 Lem 作者关于内部实现的一系列发文（日语）。虽然没有我最关心的内容（我在写编辑器 GUI），但还是非常有趣的一系列文章。

Manjaro 争议总结，比我之前机翻的那些要好许多。