> 目前使用的是 NAT

你看看 NAT 的 gateway 是什么呢。只要流量经过主机，就应该会被代理。桥接反而是简单问题复杂化

dzU2OHdAb3V0bG9vay5jb20K
支持一下

上面说 IObit 学到国内精髓的，这个公司本来就是国人出海办的啊。

IObit 在 2004 年由 Xue Tim [1]、Hugo Dong [4] 等二人创办于中国成都 [2]，国内壳子还包括 成都正欣德信息技术有限公司 [3]（底部邮箱可以看到是 iobit 的）。

有消息称 [4]：2012 年在香港借壳上市，发布所谓的 IObit Malware Fighter 杀毒软件，被 Malwarebytes 、趋势科技 指控偷他们的数据库。

[1] https://www.crunchbase.com/person/xue-tim
[2] https://www.highperformr.ai/company/iobit
[3] http://zhengxinde.co/aboutus-events.php
[4] https://forum.gamer.com.tw/Co.php?bsn=60553&sn=24107

我最近使用 AI 最多的场景是做调研，例如：技术选型、框架推荐、报错的解决方案搜索等等。

用的都是各自最好的模型（ Claude 4.5 Opus 、Gemini 3 Pro 等等）。使用下来：Claude Research >>>> Grok DeepSearch > ChatGPT 深度研究 > Perplexity AI > Gemini DeepResearch >>>>> 国内一众 AI （如 Kimi 、豆包等的联网模式或 Agent 模式）

点评：

- Claude 的 Agent 系统实在太强了，很多调研我自己人工做，都没有它总结得全面

- Grok 算是做得比较早的，但 Grok 4 不思进取，被 Claude 后来居上了。目前的质量只能说远远被 Claude 甩在身后

- Gemini 模型本身强，但 Agent 系统做得一坨屎。DeepResearch 不如改名叫 LongReport ，任何一个简单的问题都要生成大段信息熵极低的调查报告，充满各种无用的套话、官话、废话，研究的意义和背景写得比研究结论还长，调查的覆盖面也很狭窄，稍微困难一点的问题几乎碰不到正确答案的边缘。像是公务员用来糊弄不懂技术的领导的

- 国内的模型能力可能很强，但受限于合规性，只能调用国产搜索引擎，再加上信息孤岛化，Garbage in, garbage out ，搜索功能全是垃圾。别说是不常见的问题了，即使常见的问题 90% 也都是幻觉般的胡言乱语，可信度不超过 10%

天下苦 Wayland 久矣。X11 是太开放导致安全漏洞多，那 Wayland 就是太封闭导致什么也做不了：

1. 宁愿提供一个个独立的、随意设计的 Protocol ，也不愿意像 macOS 那样设计一个统一的权限系统。

现状就是：有的功能需要用户显式授权、有的功能需要请求后 Compositor 自行实现（例如移动窗口）、有的功能不需要授权可以直接调用。设计选择完全看协议发起者的心情；

2. 通过新协议的速度慢得令人发指。

人人参与讨论的结果就是人人都不满意，一个协议讨论五六年仍然有「原教旨开发者」会反对（例如屏幕截图 ext-image-copy-capture-1 、置顶显示 wlr-layer-shell-unstable-v1 、全局热键 hyprland-global-shortcuts-v1 ）；

3. 碎片化。

由于上一点中所说的原因，很多协议把社区开发者熬走了都还没 merge ，各家 WM/DE 只能自行实现私有协议。目前 wlr 、KDE 、Hyprland 、COSMIC 、Weston 、Treeland 、AGL ，只要你能叫出名的 WM/DE/framework ，都有一大批自家的协议来补充那些 Wayland 不合并的功能。另外还有一些已经合并但下游开发者不想/不能及时支持的功能。

> 内存安全

Rust 的「内存安全」一直是相对 C/C++ 这种偏底层语言说的。

Go 、Java 、Python 、… 根本不存在内存问题，当然也是内存安全的。Rust 相比 Go 在这方面没有任何优势。

当然如果是说「空安全」，那又是另一件事了。

> 模式匹配

这个在 Go 2 讨论特别久了，用模式匹配势必会带入一堆新问题，所以看你的具体需求。

即使是 TypeScript 编译器这种重数据结构的活，微软也已经证明了能用 Go 写的。

openai + claude + openrouter + … 可以混用，方便测试不同来源的模型

其他高级功能我尽量不用

@radiobooks18 我也觉得很怪，

第一反应：是不是哪里没设置对？ => 捣鼓各种优化工具后依然卡

第二反应：是不是系统出问题了？ => 重装后依然卡

第三反应：阿三对新硬件负优化了？=> 回 Windows 10 LSTC 后，好一点，但还是比出厂时卡，比 Arch 则卡得多

第四反应：我不配使用婆罗门系统……

我现在的新电脑是 Windows 11 + Arch ，两边都还算流畅。所以可能真是毗湿奴大神发力了，而且还是云控发力

@radiobooks18 配置如下：

CPU：AMD Ryzen 7 4800H
GPU：AMD 核显 + NVIDIA GTX 1650
内存：16GB
硬盘：三星 SSD 1T + 西数 SSD 1T

是这样的。我大学本科的时候有个老联想游戏本，出厂预装的是 Windows 10 。后面为了学开发，直接一狠心换到了 Arch Win 双系统（主用 Arch ），一用就是两三年到毕业。

国庆节把这老电脑翻出来，滚了下 Arch ，一千多个包要更新，更新完、重启，一点问题都没有，并且很流畅。

又顺手把 Windows 更新了一下，直接更到 Windows 11 24H2 ，重启完卡爆了，右键菜单要四五秒才能弹出来、资源管理器卡得动不了、动画帧数都是个位数，右下角不停弹小控件，我还以为电脑中病毒了。回 Windows 10 LSTC 也依然巨卡无比。最后折腾了一圈，还是回去用 Arch 了，顶级流畅

阿三的印度神油系统对老硬件还是太不友好了

业务逻辑不要害怕造轮子，协议标准不要自己造轮子

开始开发前约定好规范，如「逻辑上可空的变量用 nil pointer 还是空值表示」「可选参数配置用 option pattern 还是 builder pattern 还是生成重载函数」

Be stupid ，不要耍聪明省代码行数而写出费解的代码。Go 很冗长并且它就该冗长，冗长比晦涩好

@PrinceofInj 哈哈，我也差不多。之前对 rime 的印象一直就是手摇拖拉机，干啥都行等于干啥都不行，事事都要自己写代码配置，配来配去折腾一两个礼拜还不如 Windows 上微软输入法开箱即用的体验。Fcitx5 Pinyin 就更简陋了，而且不知为何从输入到显示候选总是慢一拍。

后面直接用了万象，第一次感觉 Rime 还能这么简单好用。

> 感觉万象主要还是在调整词库，ngram 的语法库似乎并没有感觉有太明显的作用

确实。不过总体来说万象的输入舒适感虽然和搜狗输入法这种依赖云端的还不能比，但肯定是本地输入法里最强的一档了。

大厂的方案我不清楚，但确实见过一个开源实现 mvisor： https://github.com/tenclass/mvisor-win-vgpu-driver

AI 训练，开源，拼音，我看标题都以为这是 万象拼音 的推广贴了

不过万象拼音确实不错，可以看看： https://github.com/amzxyz/rime_wanxiang/

它本身是在语料库上训练了 ngram 预测器，算是有 AI 加成。实际输入的体验也不错。我自己已经用了几个月了，对长难句的支持很好

（注：非广，也不认识作者，甚至都没加官方群）

怀念的不是当时的系统，而是当时的软硬件生态。随便拉出几个当年的软件和今天的软件一对比，就看出差别来了

好奇《天国：拯救 2 》为啥一直不温不火？因为是续作？名字起得太小众？游戏节奏太慢热？

我自己没空玩但我看朋友玩了，不管是游戏自由度、世界观和文案文本量、配音工作量，还是开放世界建模和渲染水平，应该都是业界顶尖的水平。

我今年玩了《丝之歌》和《双影奇境》，云了《 33 号远征队》。说实话我大力支持《丝之歌》拿最佳独立游戏，《 33 号远征队》玩法创意不错，但前面这几部的制作水平应该还没法和《天国：拯救 2 》扳手腕……

不错，我今年也给家里人（包括我自己）换成 iQOO 全家桶了，顺便开了 vivo 家庭会员，可以共享云盘空间。体验很不错

一直觉得手机护眼是个伪需求。

看了一下 OP 之前的帖子，主要是要阅读吧。为什么不直接买墨水屏的电纸书或手机呢？

（我主要写 C ，没写过 C++，所以下面一部分说法可能不准确。）

这个问题其实有系统级和语言级的两层，一是 Linux 对 C/C++ 依赖的管理没有明确的定义，各个发行版自立山头；二是 C/C++ 的包管理本身确实很乱。

1. 对于前者，可以认为在依赖管理这件事上，Linux 没有规定什么做法是标准的，所以「每个系的发行版都是完全独立的体系」，不应该像 Windows 7/8/10/11 那样当成同一血脉的系统来看待。

尽管大家可以找出一些最大公约数（比如大多遵循 FHS 、使用 pkg-config 和 gcc ），但在实现上会有非常多细微的差别。大部分差别在开发过程中可以消解掉（例如使用 CMake 的 find_library/package 过程）但不是全部，而在打包和分发过程中则完全需要各个区别对待（比如 Debian 系、Gentoo 系和 Redhat 系，在分割软件包的粒度和指定依赖的方式上，做法都完全不同）。

此外，Linux 本身又是极度依赖 source-driven 的，需要时刻考虑用户利用现有环境进行开发的可能性。这就是为什么 Linux 下很难有 vcpkg 这样一个独立的、和系统无关的 C/C++ 包管理器。或者说即使有了，也不会好用，因为你最终还是要为每个发行版、编译器和依赖组合付出额外的成本去适配。

2. 对于后者，你的例子其实就是很好的典型。「通过 pacman 下载的 boost 似乎没有提供 .pc 文件」，是因为 boost 这个库本身只提供了 CMake 模块。你用 pacman -Ql boost 就能看到，boost 提供的是 /usr/lib/cmake/Boost-xxx/BoostConfig.cmake 配置文件，而不是 pkg-config 文件。

这种四世同堂的局面很多，不是每个包都会提供 pkg-config 来兜底（从功能性上来说，CMake Modules 无疑是更先进的）。这其实也是生态碎片化的体现：开发中的选择一旦多起来，开源作者都会习惯性选择自己最习惯的，而不是兼容性最好的。你问「有没有办法用统一的方式导入」，其实就和前端问「有没有办法在我的 React 项目里导入其他 UI 框架的控件」是一样的。当然这边的问题至少理论上是 solvable 的。

----


所以我能给的建议是什么呢？

1. 如果你专为某个发行版开发程序：完全本土化。使用那个发行版和系统包管理器，完全遵循那个发行版的逻辑。系统提供什么就使用什么方式引入；

2. 如果你为所有发行版开发程序：防御性编程，减少假设。同上，但是尽可能不要依赖某些假设（例如「一定有 pkg-config 」）。CMake 的 https://cmake.org/cmake/help/latest/guide/using-dependencies/index.html 介绍了通用的建议，主要是 尽可能使用 find_package 来引入依赖、使用 FetchContent 来从源码编译依赖 及 不要使用 FindPkgConfig 。