kuanat

@oblax #31

x390 不知道你说的哪一代，无论是整机功耗还有电池容量，和现在的机器都没法比了。

只有比较新的平台（ 7nm 之后）才能做到我说的效果，最起码进入待机之后要在 0.5w 以内，这样才能做到 60Wh 常规容量还能待机比较长。之前 14/22 工艺的平台，cpu 可能待机不会差太多，但是主板等外围设备进入低功耗状态之后耗电太高了。这里主要是强调平台要新，比如 intel 12/13 代移动版 cpu 能效比很差，但不妨碍这些平台的笔记本盒盖待机依然能有很长时间。

是不是该用跨平台框架来写 ui 是个哲学问题，即便你的立场为是，还是要继续抉择，要每个平台都用相同的（非原生风格）自定义 ui ，还是要每个平台上用原生的 ui 。基本上后者都是走浏览器了，因为没人或者团队能承担得起这样的维护成本。

在跨平台、自绘 ui 这个场景中，本质上要看在各个平台上底层用的什么 api ，楼上有人提到 go 的 goroutine 与系统线程 pinning 相关的硬伤，这个确实无解，因为现在的操作系统都是同样的 ui 线程逻辑。

这种项目最大的困难是长期稳定地维护下去。而且通常来说好看、小巧和兼容性强是不可兼得的。以 win 为例，想要小就必然对接 win32 api ，用这个写现代界面，光一个 dpi 自适应就头大。到了 linux 又会面临是 gtk/qt 还是协议层造轮子，qt 因为授权大部分时间会被排除在外，如果是直接 wayland 协议开始写，且不说什么消息循环都要手动，就天天跟着上游更新都是很大的工程量。

当然如果写的项目不需要长期维护，这类 ui 框架还是很有市场的。

64g 内存是个不太好达成的条件，多数都要上顶配或者定制款，加上 16 寸也是个小众品类，能选的不多。

我是 16 寸 linux 多年的用户了，按照条件来匹配的话，thinkbook 16+ 是符合预算的，插槽内存，而且我确认主流新版本 linux 是开箱即用的，包括指纹这种设备都正常。发售的时候 libinput 没更新 quirks 会用不了触摸板，现在没问题了。

另外我说几个不太容易注意的点，现在大多数设计上看上去比较好的笔记本，都为了减重或者造型选择了 oled 屏幕。作为开发者来说，我更推荐 lcd 的型号，主要是 oled 的防烧屏功能 linux 基本上不可用。

另外你是 mac 用户过来的，肯定习惯了高 dpi 屏幕。我是更建议分辨率在 3200x2000 即整数缩放 1600x1000 以上的，因为 linux 生态的问题，分数缩放并没有那么理想。2880x1800 也可以接受，但 1440 水平有效宽度很多时候对于开发来说不够用，如果是前端这个问题会更明显。

之前我在别的帖子里回复过如何用 live usb 安装盘配合 来测试 linux 兼容性 https://v2ex.com/t/1128164

这个话题站里出现过挺多次了，我之前大概说过结论，越公版设计越稳定，intel 集显型号比较容易达成。

Windows 是不是有什么负优化我不知道，至少我个人用 linux 来说，从 2011 年之后我手上的笔记本就是随用随开，modern standby 或者叫 s0ix 待机，满电可以稳定一周以上，从来没有过放包里异常发热的情况。

这个主要是看硬件平台，前些年 intel evo 认证的几乎都可以，现在这个东西也没了。

这个话题属于懂行的不愿意讲（毕竟多数都会涉及黑灰产），而不懂的基本说不到重点的那种。我就简单总结下算是抛砖引玉了。

浏览器从来都不是可信环境，理论上没有任何办法可以稳定 100% 准确区分真人和机器。

对抗爬虫或者 bot 的基本思路就是提高攻击成本。比如登录之后才能看的，就有帐号成本，限制访问频率的，就有 ip 成本，甚至 cf 五秒盾也可以理解为采集时间成本。

想要提高攻击者的成本，那防御方也要付出代价，比如设想个极端场景，防御方要求所有请求都过一遍 recaptcha ，那防御方确实提高了攻击方的打码成本，但自己也付出了带宽成本，以及造成不便损失正常客户的成本。所以防御方更希望的是，有纯软件的方案，只付出开发成本和少量的运营成本，就能大幅提高攻击者成本的方法。于是就有了各种检测技术。

我这里随便列举一些常见的技术，以及攻击方的应对策略：

1. tls 指纹检测

因为浏览器和常见 python/go 等编程语言的底层 tls 库是不一样的，通过在流量入口做 ssl offloading 的时候，顺便检测一下请求中的 kex （密钥交互）配置，就能起到很好的筛选作用。

应对方式也比较简单，替换 tls 库或者伪装成特定的指纹配置即可。

2. 额外校验字段

同样是针对看请求直接构造接口数据的。在常规业务字段之外增加校验字段，一般由 js 代码执行后产生。

这种可以通过 cdp 控制浏览器或者跑无头等方式绕过。

3. 浏览器环境检测

基本上是前一种方法的增强版。既然攻击者能用真浏览器来伪装，那就检测那些不合理的参数，比如窗口 viewport 大小，一些特定的全局对象等等。到了这一步，基本上标配都是 js 混淆了。

对于水平不高的检测，有经验的攻击者大部分能根据调用栈定位到关键函数方法，绕开检测逻辑直接生成校验字段。

4. js vmp 混淆

基本上这就是最后的防线。把前面各种检测技术打包起来放到 js 中，然后用 js 代码写个虚拟机，再把原始的代码编译成虚拟机指令。这个对抗手段是针对人的，就是拉高对攻击者的技术门槛要求，逆向 vmp 类混淆是要比前面都难的。

从攻击者的角度来看，硬怼 vmp 还原 ast 指令也不是不行，就是累，而且没办法保证这次逆向出来了能用多久。毕竟防守方的策略是，换个混淆参数就是新虚拟机了。

所以多数情况下都是把 js 代码完整扒出来，把它当黑盒来调用。因为外部 js 环境和浏览器不一样，缺少浏览器的很多对象，所以有个专门的说法叫“补环境”，让 js 代码能正常运行。想要知道 js 代码都检测了哪些环境信息，又有一些插桩、自吐的应对策略。

就算实在搞不定，专门搞一个浏览器，就真实地跑校验字段生成，然后把结果给其他自动化的部分用也可以。


大致上就是这样了。对抗的路线最终都会转换成为“对抗成本”的问题。而且从技术原理上说，攻击方是永远可以看到代码的（尽管可能是混淆版本），所以根本藏不住。

@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 用户提的方案很难被接受，尽管开发者很努力地尝试理解，但在这个底层处理机制之上做修改还是太难了。现在什么情况我不太清楚。