@Cu635 #62

我没有用过 K50 这个型号，不是很了解。常规来说 EvoX/Crdroid 可能用得人多一些。但这个东西说到底都是一两个人在维护某个机型的 rom ，所以还是多试试。

@charles0 #51

我觉得“wayland 显示协议层面实现安全性”和“wayland 因为安全性拒绝了（应用获知窗口位置功能）实现”是有差别的。wayland 从来没有保证过什么。

就我个人的理解 wayland 协议就是一个特化的二进制 ipc ，它拒绝大多数非必须的功能提案进入核心（ foundation ），安全性是这个设计框架的副作用。

实现了 wayland 协议的合成器，一样可以实现 wayland 标准之外的功能，比如让应用获得自身位置，或者让非焦点应用获得全局键盘输入，让它变得更像 xorg ，让它变得不安全。这些功能写成提案就变成了所谓的扩展协议，如果 wayland 不认可，那就变成了私有协议。

我想表达的意思是，wayland 的设计好坏不能单纯以纸面上的协议 specs 来评价，也不能单纯以各种合成器已实现的部分做评价。

Wayland 的发展是有过重大转型的，原本的设想是 kdbus （也就是 dbus 的内核实现）为基础，但后来内核拒绝了 kdbus ，导致 Wayland 不得不依赖 systemd/dbus/pipewire/portal 一系列机制打补丁。现在 wayland 的样子很大原因是为了落地而做的妥协。

现在 linux 的现实就是，上面提到的这些底层机制，几乎绝大部分都是红帽员工写的，没得选。既然没得选，评价好或者不好就不那么有意义了。或许有人会说 xorg 也是一个选择，现实情况是没人想维护了，很难说用爱发电的 x11libre 能走多远。

我感觉大多数人可能并不了解一个桌面系统是要有多复杂，所以会产生误解。之前我写过一篇介绍 wayland 合成器的，等有空我完整写一下关于桌面的。

简单回答一下这个帖子里提到的一些问题。我不是为了评价它是好是坏，只是尽量补充些信息。


- 全局热键

底层逻辑是非焦点应用不能获得键盘输入。所以 wayland 核心协议（ foundation ）没有，实际 org.freedesktop.portal.GlobalShortcuts 是属于 XDG Desktop Portal 的一部分，之前是 flatpak 沙盒环境的实现。或者再底层一点，wayland 只涉及二进制高性能 IPC ，其他的都走 dbus 。目前 KWin/Mutter 都支持了，hyprland/sway 虽然不直接支持，但对于用户来说反倒更简单，只是对应用来说缺少注册机制。

- 应用获知自己的位置，XY 坐标系

底层逻辑是窗口位于哪里是用户和合成器的事情，而不是应用程序的事情。安全考量是防止 UI 欺骗和覆盖攻击。这个问题协议层面无解，但作为合成器来说以私有协议方式实现这个功能不难，至于为什么不做可以去问开发者。

- 远程键鼠

X11 的方式是无限制的事件注入。Wayland 认为这种无鉴权无溯源的方式不安全。目前有两个解决思路，一个是走 XDG Portal 通过 libei(emulated input) 完成，另一个是 uinput 创建虚拟设备。这个只能说是软件更新没跟上，至少我用的 wayvnc 和 gnome rdp 都很正常。

- 类 macOS 统一权限/碎片化

历史原因不存在这个基础，实际上现在 systemd/dbus/wayland 这三个支柱，80% 代码都是 RH 出钱雇人做的，最大公约数就这水平了。不同于现实世界的标准之争，资本或者组织先确定标准，再去搞实现。Wayland 的现状是反正总有人不满意，纸面上的协议没什么意义，一堆私有协议最后卷剩下的那个才是真正的标准。

- 输入法

这个提过很多次了，fcitx5 实现了所有可以支持的协议，主要合成器也都支持至少一种协议，剩下就是软件自己的问题了。问题是输入法这协议都是老外最早设计的，他们根本不懂，所以只能我辈努努力改变现状了。



PS

我知道很多人有 RPA 或者自动化的需求，如果是开发者，在合成器基础上手搓“私有协议”不是很难的事情，如果是普通用户，基于 sway IPC 可以达到几乎任意想要的效果。如果是楼主这种开发应用发现没有办法适配我能理解，如果只是单纯抱怨那就没意思了。

先看许可采购名录，再从里面挑。有些要求严格的比如银河麒麟和麒麟信安就不是一个东西，保密级别高的只能用后者。

SpringBoot+MySQL 是没什么压力的，ARM 都可以，性能也基本够用。你要是不知道怎么报价，先去找软件厂家问采购价，然后再根据采购价往上加。麒麟系统是提供 jdk 的，1.8 版本什么的都有，可以省钱。另外东方通什么的可能比你想象中要贵得多，因为有些国产化的要求是连中间件一起的，没得选。

多数这种项目最后会卡在数据库优化上，有自己的工程师可以试试看，搞不定就要付费请厂家的人。就我个人经验来说，金仓的工程师水平是比较高的，他们家 oracle 兼容比较好。至于 MySQL 这种国产几个都没什么压力，自动化迁移工具都很成熟。

先考虑提升硬件看看。

以全量编译 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 ，就是出现网络分区的情况下，每个分区都不会下线，所有节点都会继续工作，但由于分区之间无法通信，就会导致不同分区中的节点自从分区产生时因为写入不同而产生分叉，因而失去一致性。