@Slurp 构建事件和分发体积互斥。KaTex 如果要在服务端渲染，时间肯定会超。
我倒是觉得用 Hexo 慢点没啥关系，缓慢的构建通常只发生在第一次，你不可能每次都新增 100 篇文章。

@livid

？服务器上 snap ，这可太勇了

对于用户，我们要支持空格 /非 ascii 路径。
对于程序员，一般都会习惯用 ascii 非空格路径，terminal 里头敲路径方便。

CroptoJS 由于 JS 本身的 weakness ，库作者偷懒，**某些半吊子前端瞎 JB 写**等原因，可以作出很多奇怪的非标准操作，例如 5 楼提到的 key 长度，之前还碰到过有强行把加密后的数据当成 utf8 传进去的，我当时看到负数码点的 utf8 差点吓死，但它也跑得好好地。
最好的方案还是 6 楼所说的那样，找个轻量的 JS 运行环境跑一下 CryptoJS 。如果要避免，就只能手动修改本语言的加密库以放宽限制。但这通常非常麻烦。

哦上边已经有人提到了，scratch 没有任何东西，也没有 core-utils ，那就别折腾了呗。

bing 搜索 “docker shell”，第一条 stackoverflow 就是正确答案。我看了下第二条的文章更简洁： https://www.baeldung.com/ops/docker-container-shell

总结就是如下命令，新建一个基于 ubuntu 的容器，进入容器的 bash：
sudo docker rename $(sudo docker run --network=host -h docker -d ubuntu tail -f /dev/null) hi
sudo docker exec -it hi bash

差距是有，但大多数时候，差距都体现在应用层协议的实现上，比如 http 的实现，syscall 的开销，tls 等。如果只是开一个 connection 一直读写，通常情况下几乎没有差异。
越底层的东西，tcp 甚至 udp ，差异是很小的。

那是 1.70 ，不是 1.7

先白屏，过一段时间没加载完成再显示 loading ？

vite 似乎是用 esbuild 做的，也许可以看看 esbuild 的文档，或者应该有类似 clang-cl 那种解析 tsc 格式的命令行参数再喂给 esbuid 的工具。
还是建议改掉 error ，也不是什么难事。如果是做迁移，就暂时 Any 一把梭或者 allow js 。

反正纯 golang 的交叉编译方便得很。
golang 的 loongarch 后端贡献者似乎就在 v 站呢，之前看到过他发帖。

哇，好羡慕，再低头看看每天图书馆宿舍两点一线的我… 每天的运动量就只是骑车往返，加起来不到 10 公里…

建议直接输出 m3u8 ，会自动切好 ts ，然后再批量转回 mp4 。
使用 -c copy 参数，不会重新编码。

总体上就是如下建议：
1. 随大流，使用流行的发行版，Ubuntu 、Fedora 。
2. 保持平庸，保持默认，尽量不要做“自定义”。
3. 做好备份，利用 BTRFS 或者 ZFS 的快照特性。

唔，我的想法是，更新可以更新，但尽量不要“改动”。比如把 Ubuntu/Fedora 的 Gnome 换成 KDE ，把文件系统换成 f2fs ，在系统里直接使用 pip 装东西(这和在 windows 里不一样，linux 下不隔离直接使用 pip 很容易造成混乱)等等操作。

保持系统的默认配置，**给什么就用什么**，如果是 Gnome ，少装或别装扩展。没事干的时候 dnf upgrade 一下，几乎是不可能出问题的。

不要觉得用了 Linux 就应该“定制”，“自定义”。享受“自定义”的快感，就要承担增加的崩溃风险。我们都是普通人，适合别人的东西，也适合我。每个在发布前数轮测试的稳定版本，在“一切皆默认”的时候，真的通常要比 Windows 稳定得多。

也许会有很多人反对，但我的观点是：“最稳定的方案是默认”。
无论使用何种发行版，尽量保持默认设置。使用默认桌面环境，默认主题，默认字体。很少会遇到问题。
要折腾瞎搞的时候进 docker 或者 qemu ，尽量保证系统的原始状态。

什么是“钱包机器人”呢？我没查到这个词的解释。