yanqiyu

某种混杂了 Fedora IoT/CoreOS 的 rpm-ostree 技术的 Fedora Server ，然后上面跑很多容器

vscode 的 clangd 插件配合 clangd

上面用串口是个办法，也可以试一试给主机配 kdump ，看看能不能抓到 crash 的日志。

另外有没有配 pcie 直通？

听起来很危险，感觉不如在自己服务器配置 cockpit ，把登录凭据拿出去怎么想都不是正确的行为

把 secure boot 也关了就是了

@w568w #9 还是会绕不开统一分发的问题，比如 A 程序依赖 B/C 两个库，但是 B 是编译链接到 2024 版本的 stdlib 但是 C 是链接到 2025 版本的 stdlib ，这么下来依旧会出问题

结果就是整套动态库都得有多个版本。

@hwdq0012 这个取舍，就是哪天 libc 出现 CVE 你就会惊讶地发现所有软件都弹出来了安全更新。😂

静态链接 libstdc++/libc++我觉得很正常啊，只是这时候要保证引用到/会 dlopen 的的所有动态链接库别再拉一个 libstdc++/libc++进来就行。

并且向后兼容相对容易，给符号标记上版本然后保证老版本符号永远不会被扔掉就行，但是向前兼容就基本上意味着不能加任何新的符号（因为老版本没有），除非这个语言/运行时永远不演化，不然向前兼容不现实

（其实你可以 LD_LIBRARY_PATH 塞一个自己编译的新版本的库来让程序能跑起来的，科学计算集群全员 CentOS7 的时候我经常这么干）

考虑到和 rust 的区别，rust 你编译什么东西默认都是静态链接，但是你要是真的想要用 rust 做整个操作系统的 userspace ，大范围用上了动态链接（节约磁盘之类的理由），到时候 C++遇到的 ABI 的鸡毛蒜皮一个也跑不掉。

或者说你要是能接受编译 C/C++项目的时候像编译 rust/go 项目一样把整个项目的所有依赖全部编译一遍然后静态链接，那 ABI 也不是问题。大家不习惯的原因大概是 C++生态出现在集中的包管理之前，没有包管理、和系统里面依赖 C++的东西太多了，以至于用系统的库已经成了最经济的选择了吧。

@leeyuzhe 说实话写代码的话输入法存在感不高

不过就算需要装个 fcitx5 也不是不行