我感到自己最近一直处于应激状态，随时准备和世界反目成仇、大干一场，这种状态大概是不适合做任何人生决策的，我在想应该调整调整心态，或许暑假该出去走走，也暂时把找实习的事情放一放。写作也有帮助，至少我在写词源学系列的时候心无旁骛，感到开心。

But my head is full of poison, and my heart is full of doubt

I got toxins in my bloodstream, you tried hard to suck ’em out

And it feels like medication, and it’s good for me, I’m sure

But it don’t matter how your love feels anymore

It’ll never be the cure

系统之乏与特异之悦

📜

Marcin Wichary 注意到了 1997 年的软件 ClarisWorks 的提示框设计，按钮上写的不是「过会儿再说」「现在注册」「永不注册」，而是简单的十三个字母 Never, Later, Now（永不，稍后，立刻）。这看起来违反了 Avoid “Click Here” 规则（即按钮不应该使用「点这里」等模糊的词），用户如果不读提示框上的文字，就不知道按钮是用来做什么的。

改成 Never Register、Register Later 和 Register Now 能解决这个问题，但按钮看起来就不会这么整洁了。在我看来，丢掉多余的 Register 也能避免语义冗余，字太多不但会造成视觉负担，还会造成理解负担。

Jim Nielsen 对此有些思考，他把 Avoid “Click Here” 规则定义为「系统规则」，把 ClarisWorks 看似违反规则的做法当作最适合当前软件的「本地化方案」。他感叹，如今的软件为了扩大规模，貌似已经完全用成熟的「系统规则」代替「本地化方案了」，因为前者又快又足够好，费心思设计提示框的文字不仅费时费力，还不能带来显著的回报。

As software moves towards “scale”, I can’t help but think that systematic rules swallow all decision making because localized exceptions become points of friction — “We can’t require an experienced human give thought and care to the design of every single dialog box.”

我对此的看法是，在软件行业内的商业软件兴许不必在乎特异的、令人愉悦的本地化方案，只要跟着已经工程化的、被证实有效的经验走，就能快速且稳定地交付成果。不过，真正改变人们对软件看法的软件，往往不来自商业世界，比如 Linux；就算来自商业世界，也来自那些不守规则的人，比如 Notion 和 Arc。改变世界的东西，在我看来，很少来自追名逐利、总是试图复刻成功的人，而来自那些抱有热爱，匠心胜过野心的爱好者。

不过这两类人也不是割裂的群体，毕竟爱好者也要吃饭。

不推荐 Bitwarden

📜

文章列举了密码管理器 Bitwarden 的一系列缺点。这是个商业软件，提供订阅制的服务，同时也有自托管选项，但作者表示 Bitwarden 的官方后端完全是给企业使用的，普通人部署的成本很高。当然，有社区用 Rust 实现的 Vaultwarden 作为替代后端，个人用户自托管的成本被降低了很多，不过即便是这样也要依赖 Bitwarden 的客户端（尽管是开源的，也可以 Fork）。

之后作者还列举了 Bitwarden 的设计在用户体验上的问题（由于 Vaultwarden 是实现了 Bitwarden 的 API，所以这些体验问题我想也无法在这个开源的替代品中修复），比如在密码库之间移动项目，必须先把要移动的项目以明文导出，然后再导入要迁移至的密码库中，不仅麻烦而且很不安全。有些时候 Bitwarden 客户端更新会弄坏一些东西，还有很多烦人的小细节。此外，作者还列举了从 2023 年到今年，Bitwarden 的各种安全性问题，比如前些日子的 NPM 供应链攻击就波及了 Bitwarden 的 CLI。对密码管理器来说，安全问题是致命的。

我想补充的是，不久前 Bitwarden CEO 换人，引起了不少 风波 。尽管目前看起来安好，但貌似已经有一些发疯的前兆了。我决定脱离 Bitwarden 生态。

我是前不久才自托管 Vaultwarden 的，当时只是想要快点找到一个 Apple Passwords 的替代。一方面是为了完全自己掌控数据，另一方面是长远考虑，我之后可能会半脚踏出苹果生态，去整一台 Linux PC（不过近期还不打算折腾）。Docker 镜像跑起来的时候我就心生疑惑：这东西跑在公网上真的安全吗？密码库有必要二十四小时在线吗？

答案是没有必要。再加上 Bitwarden 最近的事情，我决定完全迁移到 KeePass 生态。KeePass 用单个加密的 .kdbx 文件作为密码库，不需要庞大的数据库和 Web 服务，用户可以把密码库放在任何位置，只要能同步文件就能够同步密码库。密码库主要用主密码解锁，还可以附加密钥文件和 Yubikey 做额外的保险措施（可惜我的 Canokey 貌似不支持相关协议，我没有深入研究）。我使用的客户端是 KeePassXC ，iOS 使用的是 KeePassium ，目前暂时通过 iCloud 同步密码库。

密码库上锁之后，浏览器插件就没办法和 KeePassXC 通信，解锁需要打开 KeePassXC 而不能在浏览器里完成，所以体验上会差一些，但还算能忍受。迁移之后我使用了大概五天，目前基本满意。

前端极大化主义

📜

一种架构设计方案：如果有一些大小适中的数据需要发送给前端进行展示，过滤和排序等操作不必在后端完成，可以把完整数据直接发给前端，由前端处理；这部分数据还能缓存在前端，需要重新排序或过滤的时候不必向后端发送请求。

当然，这不适用于所有情况，只有数据量不会造成很大负担的时候才这样做。这不仅不会让网络连接不好的用户感到卡顿，反而会因为 HTTP 请求的减少而优化这部分用户的体验。很多人觉得发送所有数据不利于网络连接，但很多时候需要发送的数据甚至不如一张 JPEG 图片大。另一个理由是：现在没有那么多数据，但以后可能就有了。这和抽象层一样，很多时候人们编写了太多额外的抽象，但很久之后会发现，其实根本就用不到。

作者还引用了加尔法则（Gall’s Law）：

A complex system that works is invariably found to have evolved from a simple system that worked.

A complex system designed from scratch never works and cannot be patched up to make it work.

You have to start over with a working simple system.

大概是说，不能一开始就把系统设计得复杂，应该从最简单的可用系统开始做。

简单来说，作者的观点是，不要仅仅出于习惯划分前后端的职责，前端除了展示，也可以做基本的数据处理。哪怕不用前端极大化的方案，仅仅思考「数据处理可能不需要全部放在后端」这件事就能帮开发者设计出更好的系统。

用 PNPM 规避供应链攻击

📃

我已经在 先前的一篇文章 中详细地报过菜名，列出了近期的 NPM 供应链投毒事件，结果仅仅过了一个月， TanStack 就被投毒了。JavaScript 的包管理生态极度中心化，非常容易成为攻击者的众矢之的，而 NPM 本身的安全措施显然不够有效。如果暂时没办法离开混乱的 Node.js 生态（我们能想象一个没有 Node.js 的前端开发未来吗？），采取措施规避供应链攻击就很重要。

首先，大部分供应链攻击都利用 postinstall，安装依赖后直接在开发者的电脑上执行代码，偷取储存在本地的密钥等关键信息，那么默认禁用 postinstall 脚本执行就能避免这部分攻击。PNPM 默认禁用 postinstall，需要显式地设置 allowBuilds 允许指定的依赖执行 postinstall 脚本。

第二个规避手段也是 PNPM 默认开启的， blockExoticSubdeps 会影响子依赖的安装（也就是 package.json 中没有直接声明的依赖，是依赖的依赖） ，如果子依赖来自远程 Git 仓库或 Tarball 直链，就会默认阻拦，只允许来自受信的目录（registry）、部分受信的 GitHub 仓库和本地路径。这个手段的有效性我持怀疑态度，恶意软件也可能来自受信的目录吧，默认屏蔽所有远程 Git 仓库和 Tarball 直链不也是在让整个 JavaScript 生态变得更加中心化吗？一旦 NPM 这个中心出问题，整个生态都会出问题，而 NPM 的安全性大家有目共睹。

第三个规避手段在我看来是最有效的：推迟依赖更新，因为大部分供应链攻击都会在几小时内被发现和修复。v11 版本的 PNPM 默认推迟一天，一天内发布新版本的 NPM 包不会被 PNPM 解析。用户可以把 minimumReleaseAge 设置项改得更长一些。

第四个手段是 PNPM 的信任策略，默认关闭，需要手动开启。 trustPolicy 目前只有一种策略，即 no-downgrade。开启后，如果某个包的信任等级在更新之后下降了，更新就会失败。信任等级是通过信任证据（trust evidence），我想应该是发布者的签名之类的，文档里没有写得很清楚。比方说先前的版本中，作者有给包签名，在某次更新中没有签名，那么信任等级就下降了，此时更新就会失败。

最后，无论如何都应该使用锁文件（lockfile），锁定依赖的版本号，并且要把锁文件 commit 到 Git 仓库当中。

ggc

抱歉，我老是把名字看成某个 C 语言编译器。

用 Go 语言写的 Git 命令行工具，可以当作 Git 的简单封装层，可以交互式地执行各种 Git 命令，还能全局模糊搜索命令。许多 Git 命令可以直接用 ggc 命令替代，而且变得更友好，比如 git commit -m "" 变成了 ggc commit ""（我一直觉得 -m flag 很烦），ggc add interactive 可以交互式地选择 diff（而不是整个文件）添加到 Stage。

整体而言，ggc 比 lazygit 更接近 Git，抽象层次没有那么高，而且更像 CLI 而不是 TUI。至于怎么选就看自己的偏好了。

访问： bmf-san/ggc

• 这周玩了很多的《饥荒》和《星露谷物语》，每天不是在建家砍怪，就是在一边钓鱼，一边等谢恩下班给他送礼物——这个男人怎么这么有魅力？

  你没活干吗？¹

  我大概真的该好好干活儿了吧。

• 把《 当人们不再问好 》发在联邦宇宙上之后，被转发了几十次，貌似又小小地火了一把，收获了不少关注。和以往文章不同的是，转发到联邦宇宙上时我附加了一段 TL;DR（太长不看版），兴许我以后都应该写写这玩意儿？

• 周天去书店写东西的时候，看见坐在旁边的女生包上有一根黄瓜瑞克。

  另外《瑞克与莫蒂》第九季第一集真好看啊。

• 继 Clojure 之后学的第二门 Lisp 方言是 Common Lisp（至于 Scheme，我也说不清楚为什么，总之暂时搁置了），打算用来写个小小的 Web 应用练手。CL 的各种设计我都还挺喜欢的，比如没有 false 只有 nil，调试程序时遇到报错可以直接替换有问题的值，在不修改程序的情况下临时执行，这样可以忽略当下不应该关注的代码细节。总之体验还不错。

  另外它能直接编译成二进制文件，而不是像 Clojure 那样编译成 JVM 字节码。据说用 Common Lisp 编写的 woo 是所有编程语言编写的 Web 服务器中速度最快的，还不知道具体体验如何。

• 好久没跑步了，心率和呼吸倒是控制得非常好，不过心肺还没感受到负担，脚踝就在 1.5 公里之后不堪重负了，痛得不行。

  于是跑完之后又回来做了 10 分钟 HIIT 把强度拉上来。

  这么想起来人的脚踝真的承受了很多不该承受的重量呢。

• 词源学小知识：意大利语 ciao 的本意是「我是你的奴」。