先考虑提升硬件看看。

以全量编译 aosp 为例，在公司老的 e5 服务器上，大概要四个半小时左右。放到同事今年新买的笔记本上，70w 性能模式大概只要两个小时不到，从 32g 升级到 64g 内存之后，又能提升接近 15 分钟。后面增量编译大概在 10~20 分钟不等。

首先明确一个逻辑，就是判断一个写入行为是否正确，只能靠写入之后的再次读取来验证，但这个验证仅能代表这一次尝试读取时的结果，很可能下一次再读取就出错了。基于这个逻辑，所有的存储介质还有软件，都是不做这个检测的，而是在写入的时候，附带写入一个校验码，那么下次读取的时候，如果校验码和数据本身不一致，就认为之前写入的数据出错了。

如果这个静默错误发生在硬盘内部，比如因为宇宙射线或者某种原因造成的，那么硬盘固件会向操作系统汇报读取出错。根据你的描述来看，没有任何软件层面的提示，而是你人为校验的时候发现的，那就说明硬盘内部的校验信息和硬盘上实际的写入数据是一致的，由此可以判断，数据在进入硬盘之前就已经发生了变化。

再往上一层就是 xfs 文件系统了，由于 xfs 不像 zfs/btrfs 有数据块校验，同时会在读取的时候强制做验证，所以比较大的概率是，上一次写入时，xfs 获得的数据已经是错误的了，这个错误大概率是发生在内存中的静默错误。根据描述来看，硬件平台是没有 ecc 内存的，那么这种出错也就不可知了。

关于 bitrot 我在网上看到过很多次了，只是我个人从来没有遇到过，无论是很多年前组的 nas ，还是近几年接触维护过的带 ecc 内存的服务器，当然也有可能是遇到了但我不知道……

我目前的应对方案是 cpu 开启内存加密，因为内存是 ddr5 本身有系统不可见的内部 ecc ，开内存加密可以让 1bit 的错误传播到最多 256bit ，提高发现的概率。文件系统方面都是 btrfs ，同时也采用 luks 加密，底层存储都是 btrfs raid1 ，都会大幅提高 bitrot 被发现的可能。迁移到这套配置很久了，我依旧没有遇到过静默出错的情况。

简单看了一下，似乎没什么可挖掘的，也就 ucoilk_cn 这个域名了，有备案。

应用本身用了不知道什么的简单抽取壳，反正比较简单，可以自吐也可以手动解密。解密在 so 层，没有任何防御的 aes 加密。字符串做了混淆。总体来说防了个寂寞，连 ssl 都没有。

看子域名估计诈骗的事没少干，感觉举报或者 ddos 都不好制裁，改头换面就又回来了。似乎扒一下接口塞垃圾数据可能还有点用。

看看有没有暴躁老哥逆向挖掘一下给它举报了

楼上说米氏对比法太逗了……

能具体说一下二进制文件体积的比较标准吗？因为我看这个项目里 build 设定里面是动态+strip 。

再就是原始 run_benchmarks 的结果有吗？从测试脚本看，这个更多是加密协议之间的对比。

以我个人的体验来说，Flutter 的质量、社区生态算是比较好的了……问就是 bug 太多修不过来。

跨平台 UI 本来就是妥协方案，只能说强依赖这样的方案不是很理智，类比到现实就是一个便宜的替代方案不能期待它提供 100% 的体验。

@bczhc #2

看你这个回复基本上就是系统的 bug 了。小米的软件 bug 多到离谱，而且大多数时候管杀不管埋……

关键是从这个表现来看，在进入到 InputMethodService 之前就被拦截了，连拯救一下的机会都没有。

我来解释一下 Rime 作者为什么不接受这个实现方式，以及作者期望的可能的实现方式。

按照作者的术语习惯，librime 核心部分称为后端，也叫算法引擎，weasel/squirrel/ibus-rime 这些官方应用称为前端。这里忽略掉操作系统的输入法框架细节，搞清楚两个事情即可，一个是前端和后端之间是通过 ipc 通信的，另一个是像获取并维护输入焦点信息、输入法状态本身的管理是在前端完成的。

实际上只有 librime 后端才是输入法状态的真实来源，squirrel 这个前端只有逻辑上的 get/set 接口。由于 macOS/Linux 的输入法框架都是基于 ipc 的，所以 librime 后端实现了 Session 机制，用于区分不同的输入焦点目标。

现在 squirrel 前端的实现非常 naive ，对于每个输入目标焦点，都通过 createSession 来创建一个新的 session 。你现在的实现思路是，通过 squirrel 暴露的 set 接口，控制 librime 后端每个 session 的实际状态。

作者认为更好的方法是，在 squirrel 层面实现一个 session 复用机制，而不是每个输入焦点都用 createSession 来创建新的 ipc 连接。

这种实现方式也非常直接，我这里拿 fcitx5-rime 这个基于 fcitx5 框架的 rime 前端做例子。

fcitx5-rime 逻辑上不区分具体的 ascii 还是简繁或者其他什么状态，只关心是不是要在不同的输入焦点目标之间“共享状态”，有全局共享/应用内共享/不共享三个逻辑层次。

具体实现层面上，fcitx5-rime 维护了一个与 librime 后端之间的 ipc 连接池，对接到了 librime session 相关 api 。根据用户设定的共享状态，选择性创建或者复用 session 。

我不用 macOS 很久了，只是大致看了一下 issue 和代码，有可能说错，但我感觉这个大致的思路是没问题的。

我用 btrfs subvolumes 方案很久很久了。

准确来说 TM 的功能是两部分，一部分是类似 subvolumes 的本地快照，另一部分是备份快照到非本地设备上。

Snapper 只是自动化创建快照这个工作，备份快照本身可以用 btrfs send/receive 功能。

参考官方的设计意图：

https://go.dev/blog/errors-are-values
https://go.dev/blog/go1.13-errors

我补充一点个人理解：

Golang 语境中的错误 error 是一种可以预期的行为，预期之外的叫 Panic （对应其他编程语言中的 Exception ）。

基于这种思想，Golang 中的错误处理有两个特点：

第一个特点就是上面两篇官方文档提到的，错误是值，使用这个值的方式是 wrap/unwrap ；

第二个特点是 Golang 主张显式控制流，所有的错误都应该按照调用链传播，并在恰当的位置进行处理。

这里“处理”的含义是停止传播，即忽略也是一种处理方式。

Android 系统在语言和输入法相关设置里有个物理键盘的设定，可以点进去看看是否有切换键盘布局的选项，如果有的话切换到不使用 AltGr/Compose 的布局。印象 aosp 中有过，但我不是很确定。

这个问题说起来比较复杂。Android 系统的输入栈在内核部分和 Linux 是没有区别的，但之后就完全不一样了。因为是针对移动平台设计的，关于键盘布局的设定是和输入法、语言强绑定的。从底层修改这个按键和功能的映射是可行的，可以参考一下 https://github.com/keymapperorg/KeyMapper 这个应用。

简单说 Android 输入栈有两层，最底层和 Linux 处理输入设备一样，在内核态完成 scan code 到名义按键的映射，比如 scan code 1 代表 esc 按键。上面一层是按键和具体功能的映射，比如 A 按键的效果是 a 字符，有 shift 修饰的时候产生 A 字符。

如果你的系统可以获得 root 的话，可以看一下 /system/usr/keylayout/ 和 /system/usr/keychars/ 两个路径的文件。前者包含不同设备的 .kl 定义，代表 scan code 到名义按键的映射，后者包含 .kcm 定义，即名义按键到实际功能的映射，也就是一般所说的布局。可以检查一下是否正常。

如果你可以用 onKeyDown 获得 COMPOSE 事件的话，可以在编写的代码里强行当作 alt 来处理。

这里有两个可以独立实现的需求。

提供用户界面的状态指示，状态本身可以依赖 win 环境的 ipc 机制，也可以使用轮询，只要能达到目的即可。

至于控制设备本身的状态切换，主要看摄像头设备连接在什么总线上。如果是 usb 总线上，控制方法就非常多，基本上断电上电就可以，而且很彻底。如果是连接在 ipu 等总线上，通常需要走 acpi 。

说点跑题的事情，C++20 才引入 Modules ，等生态成熟还早。ESM 应该会成为主流，就是时间可能会很长……

另外我个人认为，任何现代语言都应该有 opinionated 官方统一 fmt/lint ，当然老语言没办法。

LineageOS 现在是很多 custom rom 的上游，涉及型号众多，main tree 基本上是不包含特定厂家的 binary blob/firmware ，同时也不带有 play integrity fix 之类的补丁，也一般不带厂家的相机应用什么的。所以如果要日常使用的话，可以使用基于 LineageOS 的下游改版。

一般来说，常规 integrity fix 能通过 device 等级的检测，要过 strong 等级就要特定的 keybox （因为需要 TEE 参与），这个主要影响的是支付功能。不过以目前主流的 ksu 等内核 root 方案以及改版来说，可以应对大部分应用的 root 检测。针对一些特定应用用到的检测机制，也有一些注入类的解决方案。

如果有一定开发能力，基于 LineageOS 做个修改，是个不错的选择。我有台测试机就是自己集成了一些厂家 binary 和各种 fix ，用着还是挺舒服的。除了第一次做的时候花了不少时间，后面随着上游更新自动构建不是特别麻烦的事情。不过当主力还是要注意备份，这种折腾的设备刷机还是有风险。

换个理解方式，CAP 描述的是三选二的困境，你要比较的是不是 A/C/P ，而是放弃 A/C/P ，反过来说就是 CA/CP/AP 。

一致性 C 代表所有节点在任意时刻的数据总是一致的；可用性 A 代表每次请求总能获得数据，即便它可能不是最新的；分区容忍性 P 代表系统产生分区的时候，仍然能够继续运行。

CA 或者放弃 P ，这种情况非常少见或者说几乎不会这么设计，因为网络故障总是会存在的，一个不具有分区容忍性的系统没有现实的适用场景。

CP 或者放弃 A ，就是出现网络分区的情况下，让部分节点（即某个分区的节点）下线，只使用（特定分区）的其他节点提供服务。此时对于依赖已下线分区节点的客户来说就是失去了可用性。

AP 或者放弃 C ，就是出现网络分区的情况下，每个分区都不会下线，所有节点都会继续工作，但由于分区之间无法通信，就会导致不同分区中的节点自从分区产生时因为写入不同而产生分叉，因而失去一致性。

真要发截图的话，不要发浏览器的，特别是 chromium 系都是用的自己的 skia 实现。和一般意义上 Linux 说的 Pango/Cairo 不是一套东西。


@artiga033 #45

我还真用 Linux 写自己的游戏，甚至会用 Proton/Wine 测试 Win 版本。当然如果是工作搞 C# 什么的该用啥还是用啥。

至于 PowerShell 我不好评价，对于 Linux 思维来说太多东西反直觉。其实大家用 bash 倒不是因为它有多好，更多是因为它普遍，也足够简单。多数时候我交互 shell 都是用的 fish ，但写个什么 github actions 之类的还是用 bash ，这种场景上什么 python lua 会感觉很奇怪。

如果你需要 Windows 次像素渲染的效果，可以通过 fontconfig 的配置手动开启，这个技术的专利已经过期很多年了，当前的发行版都有相关的实现，不需要额外补丁。

不过即便开启次像素渲染，你在 Linux 的感受和 Windows 也会有比较大差别。因为 Windows 的默认渲染策略是强 hinting ，在矢量图形光栅化的时候，尽可能对齐像素网格，牺牲字体还原性换取可读性。Linux 目前主流发行版的默认设定都是弱 hinting 策略。

在当前 Gnome/KDE 都转向了 wayland 合成器，次像素渲染是个会起到相反效果的技术，所以各大发行版都默认使用 grayscale 算法而不是次像素实现抗锯齿。这是因为次像素算法依赖显示器像素排布，一方面显示器的像素排布很多都不是常规 rgb/vrgb 了，另一方面这个技术最多只能在一个方向上提高分辨率。

最大的问题还是高 dpi 显示器上的缩放，次像素算法的前提假设是它输出的位图会 1:1 映射到物理像素上，然而这一点在有缩放的时候并不成立。强 hinting 策略在高 dpi 有缩放的情况下，也不是一个好策略。这里说起来比较复杂，可以简单理解为先放大再修正，比起先修正再放大，前者能够保留更多信息，最终渲染效果也会更好。

现在 Windows 新的 UI 框架编写的应用，在有缩放的情况下也会默认禁用次像素渲染转而使用灰度渲染。

以我个人的技术观点和常年 Linux 使用体验来说，我认为 Linux 的字体渲染是比 Win/macOS 都要更优秀的。

Linux 开发者大概是软件开发领域中，最能用爱发电的一群人了。

我这里引用 GNU 宣言中的一段文字，感受一下其中蕴含的的精神：As a result, a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him. 中文译版是：其结果是，如果有用户需要更改系统，他总可以自由地自己修改或雇用其他程序员或公司来改。用户就用不再祈求拥有源代码的那一家公司或那一个程序员来帮他修改，没有人再处于独断的地位。

这份宣言写于 1985 年，所以单纯引用一句话可能会有断章取义之嫌，建议还是看完整原文比较好。脚注中特意提到了，自由和免费虽然都是同一个词，但在宣言中取的是前者。

Linux 的软件生态是由成千上万的用爱发电开发者无私奉献支撑起来的，绝大多数开发者的初衷是，我开发这个软件解决我遇到的问题，它有可能帮助到其他人，所以我把软件开源出来。因为大家都清楚使用这些软件的，极大概率都是和他们一样的 Linux 用户或者开发者，所以几乎没人想拿这些软件来收费。

抱怨 Linux 应用不够好的一般都是以下两种情况：

- Linux 上没有（其他平台上有的） XXXX 软件，生态很烂
- Linux 上 XXXX 软件不是按照我的需求和使用习惯来做的，很垃圾不好用

软件的开发者不会逼用户一定要用它不喜欢的软件，反过来作为用户也不应当指责特定软件的开发者。

设想一下如果换你作为开发者，你为了满足自己的需求开发了一款软件，这款软件有 A/B 两种实现方式，你觉得 A 对你更合适就实现了 A 方式的版本，然后你将它开源出来。这时有人提出来，就不能用 B 实现吗？你会是什么反应？按照 GNU 的精神来说，你完全不需要理会。有人想要 B 那就 fork 之后去做 B 实现好了，不管他是自己动手还是雇人开发。再换个情形，如果他提出的付费赞助请你开发 B 实现呢？你可以选择接受也可以不接受。

举这个例子是想说，Linux 生态看上去的分裂，实际上正是自由精神的体现。无论开发者和使用者都是平等的，不满意就另起炉灶重做一个，没有重做的能力还可以雇人来做。任何人都拥有选择的权利。即便你只是商业软件的付费用户，很可能也是因为你拥有的潜在选择权帮你节省了大量金钱，而不用被商业软件垄断收割。



PS

再扯远一点，关于 Wayland/X11 的话题。

不少人对于 Wayland 的看法就如同对 Linux 软件一样，它让我的 XXXX 软件不能工作了，所以很垃圾。首先没人逼你一定要用 Wayland 。发行版决定不再打包对 X11 的支持了，请去喷发行版。实在不行可以自己动手。

Wayland 是个协议，甚至这些协议还有很多无法获得多数认同的废案，而协议的实现又有非常多，每个实现也可以独立决定自己要实现哪些部分，不要实现哪些部分。那你可能会问，为什么不搞个标准出来？

这又回到之前的自由软件精神的问题上了。开源软件领域不同于现实，现实里面商业结盟、资本推动都可以先立标准然后躺着收费，开源软件全看自由意志，谁的实现更好，用户就用谁的。砸钱也不是不行，比如红帽给 systemd 不知道投了多少钱了，选择 SysVinit/OpenRc/... 的依然很多。没有人非要听命于某个标准或者某个组织来行事，当然完全脱离标准别人不用也很正常，比如主流几个 Mutter/KWin/wlroots 对于五六种不同的输入法协议的实现支持也不一样，反正用户有得选。

说到底，标准是看谁实现得更好，更受欢迎决定的，不服还可以继续分裂（ fork ）。最重要的一点是，有的选才是大前提，自由软件精神就是用分裂保证了选择权。没得选才是最可怕的事情。

那个 chatgpt 看起来就是基于一点事实，车轱辘话一直重复，说不到重点上。不清楚是不是提问不够清晰的原因。我这里做个简单总结。

1.
关于 GNU/Linux 的冠名，算是个历史遗留问题。实际上也有 Linux 发行版完全在用户空间也完全不使用 glibc/gcc/make/bash/coreutils 等 GNU 工具的，比如常见的 Alpine 和 Android ，但它们都能被称作 Linux 发行版，Linux 对此没有异议，同时 GNU 也是不能一刀切要求所有 Linux 发行版都增加 GNU 冠名的。所以 GNU 的要求是 Linux 内核增加 GNU ，变成“GNU/Linux Kernel”，但大家都习惯把使用 Linux 内核的发行版称作 Linux 系统了，让大家把 Linux 系统称作 GNU/Linux 系统是个不现实的事情。

到了 2020 年前后 Linux 5.4 LTS 发布之后，就没有争论的必要了。因为从这个节点开始，Linux 已经可以由非 GNU 的 Clang/LLVM 工具链完成构建，而且是生产级别可用的。这个过渡大概用了近十年时间，最终还是靠 Google 大量投入才完成的。当然 Google 本身也不是为了给 Linux 正名，而是因为 Android 开发有相应的需求。

在此之前，GNU 确实有理由要求 Linux 内核增加 GNU 的冠名，因为理论上 Linux 内核本身也是要依赖 GNU 工具链才能完成编译从而实现其功能。之后 GNU 最多要求各大发行版在使用 Linux 的描述时增加 GNU 的冠名。但由于 GNU 开发的工具使用的 GPLv2 和 GPLv3 都没有在授权中明确要求这一点，所以这个冠名要求只能停留在道德层面而非法律层面。

2.
我个人是支持 GNU 精神的，所以我会优先使用 GPLv3+ 授权。但从务实的角度上说，我更支持 Linux 的做法，也就是商业上更宽松的 GPLv2 授权。所谓的 GNU 和 Linux 哲学之争，更多是商业化的意识形态之争，体现在纸面上就是 GPLv2 和 GPLv3+ 的区别。

以目前 Linux 的代码贡献来源来看，即便去除占比一半以上的厂家驱动部分，剩余代码中来自公司雇员的部分大概在 80% 到 85%，其余部分来自个人贡献者。如果没有商业化的参与，Linux 很难发展成今天的样子。而商业化的企业愿意参与到 Linux 开发中并贡献代码，能够接受的底线就是 GPLv2 了。

3.
GPLv2 和 GPLv3 的区别主要是两点：

一是 GPLv3+ 增加了 Anti-Tivoization 条款，这个条款要求使用了 GPLv3 代码的硬件厂商，不仅要将衍生代码开源，还要提供安装运行衍生代码所需要的“安装信息”。而 Linux 内核使用的 GPLv2 并不强制要求这一点。假如 Linux 内核也使用 GPLv3 的话，那么目前市面上所有手机都要强制提供 bootloader 解锁了。这里更准确的说法是，GPLv2 认可开源 loader 加载闭源 firmware 的形式，其中 firmware 部分不被视作“衍生作品”，而 GPLv3 认为闭源 firmware 属于“安装信息”的一部分。

二是 GPLv3+ 增加了反 DRM 条款，这个条款的意思是代码中的 DRM 限制不被视作法律意义上的保护措施。衍生代码可以去除相关功能再次分发，相当于剥夺了厂家使用法律武器限制那些想要绕过限制的用户的权利。

基本上商业公司是不会有为 GPLv3+ 贡献代码的意愿的，反倒是相对宽松的 GPLv2 达到了平衡，一方面厂家确实需要像 Linux 内核这样的基础设施代码，另一方面贡献代码并不会对商业行为造成事实上的影响。

4.
GNU 和 Linux 这二三十年的争论，实际上就说明了一个事情，开源并不能保证软件的生命力，软件维护需要长期大量的人力投入，用爱发电是比不过商业投入的。

现在的大方向主要是探索第三条路，通过 Linux 基金会、Apache 软件基金会这种组织，向开源软件提供非商业资金支持的形式来实现长期维护。