https://pkg.go.dev/log/slog@master#example-LogValuer-Secret

这是 golang slog 官方示例写法，和一楼给的思路是一样的。需要通用性做成接口就好了。

@liyafe1997 #5

感谢指正，我确实说错了。

这里用技术语言来描述：S0 正常状态，S3 睡眠（持久化到内存），S4 休眠（持久化到硬盘）。

原始问题是，S3->S4 ，中间要经过 S0 吗？技术层面答案是要，但一般语境中认为不需要。操作系统在进入 S3 的时候，会注册一个目标时长的 wake event 回调，即特定时长之后转睡眠。当硬件到达特定时间点，就会 S3->S0 ，此时操作系统会检查唤醒原因，如果是用户的操作，那就继续完全恢复至 S0 ，如果是自己注册的睡眠回调，那就在只唤醒硬盘等必要设备，然后完成休眠准备进入 S4 。

排查故障先看是否能手动进入休眠，很多支持 Modern Standby 的新设备都不支持休眠了。

如果能手动休眠，大概率是 bios 问题，可以反编译 acpi 看哪里出了问题。

unbind key 的语法类似于

```
[
{
"context": "Editor",
"bindings": {
"ctrl-space": null,
}
}
]
```

回复里可能排版不正常，你可以看一下默认 key bindings 的写法，context 是上下文状态，将对应按键设置成 null 就可以。


插件我没有做，执行 `fcitx5-remote -s keyboard-us` 切换是很容易的，官方扩展 api 里面有个 process 模块。但是没有一个好的切入点让这个插件版的命令在 vim 退出插入模式的时候自动执行，最后还要回到 task 上面来。跟我这个方案没区别。

另外 zed 在某个版本之后修改了底层 key handling 的逻辑，比较接近 DirectX 这样从底层取按键状态，而不是取窗口管理器传递的按键消息，所以对输入法造成了很大影响，特别是在 pre-edit 状态下，输入法和 zed 本身在按键处理上可能产生混乱。开发者明显是不懂 ime 的，所以 cjk 用户提的方案很难被接受，尽管开发者很努力地尝试理解，但在这个底层处理机制之上做修改还是太难了。现在什么情况我不太清楚。

实践中所有这种需求场景几乎都采用人工复核的方式，倒不是因为人一定对，而是因为人可以担责。如果你的方案里要求去掉人，那这个问题就无解，除非你能为出错的数据兜底。你能兜底的程度越低，相应的置信度阈值就要拉得越高，实践中能够自动化识别的样本比例就越低。

另外单据 ocr 识别是个多少年的需求了，做这个的外包公司或者团队怕不是遍地走。这事根本没必要上大模型，传统 ocr 算法完全够用。

各种 ocr 算法方案在归一化之后的性能表现差距很小。差别大的方面是，在没有前置信息的情况下，先识别出哪里有文字，字符间如何分隔，以及判断文字可能的语言的阶段，以及整体的识别速度。

对 2000 年前后基于传统算法的方案来说，ocr 识别能力属于有多少人工就有多少智能的水平。只要是标准化印刷单据加手写的识别场景，几乎都可以暴力解决。算法判定不准文字位置、字符集，但是人知道啊，提前对单据照片或者扫描图进行畸形校正、裁切和二值化，再把手写的部分抠出来切分，最后只把识别的过程交给 ocr 。这个流程差不多是过去 20 年最主要的方案，基本上只看你归一化做得是不是细致。据我了解有些团队做久了，积攒下几千种不同的单据模板。

2010 年之后 ocr 算法过渡到了 cnn 为主，但相对于之前的暴力解法来说，没什么差别。原来甲方用了 ocr 还是要有个人负责复核，现在一样需要这个人，就算用上了什么大模型，即便出错概率极低，还是需要一个人来兜底。

如果是同一个语言的微服务，最起码还可以直接引入代码。如果是不同语言的项目混用，那几乎就只有 dsl 代码生成这一条路了。

抽象出来 common 包存放数据结构之类的定义，这个思路是对的。我大概几年前也经历过类似改造，尽管项目本身不大，但这个过程挺痛苦的，因为这个改造看的其实是自动化的水平。

我印象当时选定的方案是 git submodules ，因为这个功能在之前的工作流中几乎用不到，还专门开会做团队培训……然后是几个人花了几天抽象了一个公共数据结构定义，写了个 common 包，准备一个一个微服务重构。

这个过程中发现的各种不一致的 bug 就不提了，最大的障碍是没人敢直接用新实现替代旧的版本，尽管初期改的几个包都是挑的代码少的软柿子。而且 submodules 方案也增加了开发人员的心智负担，因为一般的特性分支工作流，需要经常在维护旧代码和开发新功能上来回切换，用 submodules 就要注意每个分支和 common 依赖版本的对应。最后是自动化运维的部门出了大力，在生产环境做了个流量镜像，复制了一部分请求到新版本部署的测试服务器上，然后看执行结果和原版是否一致。

在这之后又增加了一个人为规定，就是所有项目 repo 都必须包含构建脚本，其实就是几个 hooks 检查 submodules 是否更新或者版本对应正确。因为我们用的是特性分支工作流，只要核心的 master/dev/staging 几个分支提前做好与 common 分支的对应（技术上是对应到 commit ），common 的更新就可以通过特性分支简单合并到每个项目中，实现由上至下的传播，开发人员只要知道在当前项目的哪个分支上工作即可，不需要关心依赖的手动更新。

这样改完了效果还是挺明显的，没有各种重复、不一致的定义，ide 补全也可用。只是增加管理成本，特别是负责 common 维护的。因为基础数据结构的改变，可能影响 API ，还可能影响 ABI ，即便是结构体增加一个字段，都有可能不兼容。同时 common 的改动要伴随所有微服务模块的改动，测试一定要跟得上才行。

至于常量的部分，我认为需要根据常量本身来区分。如果是那种界面上的文字肯定是放到直接使用的包比较好，剩下大部分常量，比如服务器地址这些，我认为还是在环境变量中设置比较好。体现到项目中就是 dotenv 这种，环境不同设置也不同。这个方案需要额外处理两个细节，一个是如何集中管理或者持久化，二是一些类似密钥的不适合用明文的要如何处理。

对于单语言项目，简化处理可以用公共 constant 包，对于多语言项目来说，一般是集中定义，然后通过 sed 之类的工具在源码级别上做替换。

我的话一般会停止服务，不过这个行为取决于备份粒度。一般来说我不会把很多服务的数据放在一起备份，而是单独处理。

从应用或者服务的层面看，大多数写入行为都是非同步的，像数据库一般会设计成 WAL 同步写，主库带缓冲的形式，暂停服务可以降低不一致的“来源”。

如果备份行为是复制，还要多考虑同一批文件由于备份这个行为的造成的时间差异，这也是不一致（匹配）的来源。如果是在 CoW 系统上，先创建快照，再将快照持久化备份会好一些。

当然这个事情还是看需求场景，只是一般来说，维护一个高可用系统的备份和恢复机制更麻烦一些，停止备份再恢复相对来说更容易自动化。

@codehz #8 感谢解释。

我这边检查了一下，是我之前拦截了对 localhost 的访问，我还以为之前的 PNA 通过了呢。

我又回头确认了一遍，RCE 是两部分共同实现的，通过 api 控制是 POST/json ，本身是需要跨域的，但 clash 默认允许……第二个漏洞是配置项在 unmarshalling 的时候，解析的路径没有检查就直接使用，所以可以下载任意文件并执行。

现在 chrome/firefox 应该都会默认阻止对 localhost 端口的非直接访问，这个第一步应该就执行不下去。

我之前在关于 go 的一些帖子里提到过一个观点，因为 go 的依赖注入太普遍，也太简单了，所以 go 的依赖注入“框架”是非常不流行的。而 google/wire 也不是其他语言一般意义上的依赖注入框架，更准确地说它是自动生成初始化代码的框架，解决的是自动化的需求问题，而非解决注入依赖的问题。还有一个原因是，go 语言提倡显式控制流，所以类似 try...catch 的跳转机制，包括基于中心注册的注入依赖框架（通过运行时反射匹配），都不容易被 go 社区接受。

造成这种现象的更深层的原因，我认为在于 go 对于面向对象的抽象有两个重要的思想转变，一个是接口由需求方定义，另一个是用组合代替继承。前者就是所谓的 duck typing ，实现接口并不需要显式声明，后者是 struct embedding/receiver method ，两者结合，go 可以用极其简单的方式实现 mock 功能以及对第三方代码的复用。

作为对比，Java/C# 在设计思想上还停留在供给方定义接口的层面上，而需求方通常又不会主动 fork 修改供给方的代码，所以要“实现”一个接口，往往是通过所谓的适配器 Adapter 模式。相比于 struct embedding ，这种适配器模式尽管达到了在不修改第三方代码的前提下“实现”接口的目的，但它要求适配器要持有原始类的实例对象。

如果是 1:1 的接口转换，这种模式还勉强够用，如果是比较复杂的接口转换场景，receiver method 的优势就体现出来了，既可以对自定义的结构增加实例方法，也可以通过别名对第三方或者内置类型添加方法。C# 为此增加了 Extension Methods ，使得它能做到和 go 一样的效果。但是 Java 是没有办法在不修改代码的前提下，为已有类型添加方法的。

所以你会看到 Java 生态中，大部分的供应者在编写代码时，会首先编写接口，毕竟测试与 Mock 场景极其依赖接口。同时适配器模式不是复用数据结构，而是间接持有实例，所以会导致需要管理（相对于 go ）更多的对象实例。于是，很多大型项目会直接使用 mocking 框架来简化对于大量实例的管理。由此可以看出，go 多数时间是只需要管理自己编写的（或者封装的）实例的，这极大简化了开发者的心智负担，也减少了对使用工具管理实例的需求。

这种对于大量对象的管理需求，才是依赖注入框架的意义所在。对于实例的管理，除了初始化构造，还包括生命周期。现在无论让谁来设计一套通用的依赖注入框架，它对于对象实例本身的管理一定是全局的，也就有了所谓的 DI 容器，另一方面它对于对象实例声明周期的管理一定是隐式的，开发者可以声明 transient/scoped/singleton 之类的意图，但框架并不允许开发者自己手动管理。

回到 go 的生态来看，一方面既没有管理那么多对象实例的需求，另一方面也不提倡隐式控制流，加上 go 生态中显式传递 context 是事实上的标准，所以 DI 的存在空间就非常小了。如果非要在 go 中实现依赖注入，就好比手持锤子看什么都是钉子，解决一个不存在的问题。

我也是常年只用 wm 而不用 de 的，但事实求是地说，wm 和 de 之间的差距还是挺大的。

这几天讨论 linux 桌面的帖子里，我感觉用户分化的主因是心态，而不是技术方案。能接受的人看重的是 linux 的长处，发挥优势。不能接受的人看重的是全面，不能有短板。所以接受不了 linux 就更接受不了 wm 。

我用过一段时间的 plantuml ，不过画架构图的话元素定位比较蛋疼，各种隐藏线，还控制不准。

蹲个解决方案。

站里有 zed 节点，不过讨论不多。

现在有几个项目在用它的 gui ，印象还有国人开发的。

https://ex.noerr.eu.org/t/1056672 这个帖子里我有比较详细的评论。

我用了四五年了，作者 dnkl 的其他项目也都很优秀。

我感觉作者对于很多底层技术了解非常透彻，随便列举一下 foot 的优秀之处：

- 基于作者自己开发的 fcft 做文字渲染，fcft 的代码也非常值得一看，简单、可靠

- 基于 damage tracking 的渲染架构，速度和很多基于 gpu 实时渲染的不相上下

- 正确实现控制序列，支持 kitty keyboard 协议，主要是用于正确传递键盘事件，比如 gui->vte->multiplexer->app ，另外就是支持 OSC52 远程复制之类的指令，做 shell 交互集成

- 正确实现 wayland 分数缩放协议，text-input-v3 输入法协议

上面随便拿出来一条能做好了都非常难得。

另外还有一些可能不属于技术，但符合我技术审美的选择：

- ini 风格的配置文件

- server/client 架构的 daemon 模式

- 自带自身的 bash/zsh/fish 补全

- 很少见做对了 alpha blending （虽然方式是基于 hsl 转换）



PS

关于 alpha blending 解释：

这个过程几乎无处不在，但是由于历史遗留问题，加上又是基础组件中的实现，所以直到今天都存在大量且普遍的错误实现。

由于人眼对于暗部比亮部更敏感的特性，sRGB 之类的色彩空间是经过 gamma 矫正的，更多的编码精度留给了暗部。所以对 sRGB 来说，数值翻倍不代表亮度翻倍。所谓 alpha blending 就是模拟真实世界中光线混合，在一个背景色上显示一个前景色文字的过程，需要先将 gamma 矫正过的 sRGB 还原为线性空间，两种颜色在线性空间中混合之后，重新映射回 sRGB 空间来渲染。

如果 vte 或者其他任何应用不能正确处理 alpha blending 很容易出现混合区域变暗的情况，这一点在字符光栅化抗锯齿方面提现很明显。对于 vte 类应用可以观察一下在各种配色主题下的表现。

Fedora 也把 kde 从 spin 提升至和 gnome 版一样的官方支持的 edition 了。

我很好奇，有没有人现身说法一下日常使用 freebsd 是什么体验，毕竟相比 linux 生态还是弱了点。

https://imgur.com/5dvnkIS.png

上面图链接不对

https://imgur.com/a/5dvnkIS.png

随便从 /r/linuxmemes 里找的，没有恶意，搜 Not The Same 有很多

这个思路有意思，手动点赞

大佬的逆向工具都挺好用的 :D