分析下楼主需求：
不打游戏 -> 核显本
对笔记本风扇噪音受不了 -> 自身风扇调教要非常优秀，或者有软件能关闭风扇
非大小核 CPU -> 截止楼主这贴发布之时，市面上全部 amdcpu 或者 21 年及以前的全系英特尔 cpu
对性能无要求 -> 接受老电脑型号

楼主这个需求我知道有几款可以控制风扇转速的核显本，thinkbook 老型号，比如 21 年的 thinkbook14p 和 16p ，16p 排除掉是因为它是独显全能本。

21 年那会英特尔都还是 11 代，最后一代的全大核英特尔，但那两年性能最强的是 amd ，是英特尔的整整两倍，价格便宜两百块。有 14p 用户嫌风扇太吵送联想售后，然后售后人员测试过他电脑后忘了删除调试工具，这是联想内部控制风扇的程序和源码，然后他分享到网上，网友制作了自动化和手动控制 14p 风扇转速的软件，这软件我当年是 16p 用户也在用，确定可用。github 有链接，源码来自联想程序员：

https://github.com/markgoo/Thinkbook14PAutoFanController

你要明白一个道理：美观和直观好用是两个指标，现阶段任何软件都得在这二者之间寻求平衡，
securecrt 就是纯粹的直观好用，好用到 win 下连 xshell 都不是他的对手，但他完全抛弃了美观，丑得一塌糊涂，而且 mac 版本没有 win 的好用，crt 界面似乎没有选项可以一键调起 securefx 并自动连接（ win 有个按钮可以一键调起）。

windterm 问题是多端比如 mac 和 win 端配置文件有可能不通用，而且设计上有点限制

termius 大量文本展示的时候存在吞输出的问题，这毛病 finalshell 也有。

整体相对美观和好用的可以看看 electerm ，甚至专门做了跳板机功能，但它的问题是太卡了，所以只适合给一些现场部署人员使用

tabby 就是个终端实际体验下来用于 ssh 管理的话远不如 electerm 直观

接口工具论好用还得是国产的，我用了一圈，还是 apipost 好用，反应快，功能全，postman 打开后加载很慢，还有免费版 postman 也就是 postwoman （这货后来又改名了），功能性也不如国产的 apipost 好用

mysql 定时多地备份，然后利用校验值来对比多地备份是否存在区别，有的话报警，至于备份命令可以看看 mysqldump 这个命令，利用 linux 的定时功能来定时执行

报警问题的简易办法是所有节点相互检测对方来实现

看你实际需求，像我要 root ，除了一加没有可选项，同时我是从一加氢 os 一路过来的，coloros 即便是功能性再差，都比氢 os 定制功能多得多，还有就是看中一加 12 这个护眼，到手体验也挺不错，唯一缺点就是这逼不能贴 uv 钢化膜，否则指纹功能接近报废，其他倒没啥明显缺点

@BaymaxK 你理解错了，op 必须有一个 wan 和一个 lan 共两个口，你直通肯定不能把管理口给直通，那你就只剩一个 m2 转的口，数量不够，到头来还得是不直通，我们三人说的方法完全相同，你说到底那加装的网卡就是白买

你网卡白买，任何单口电脑都可以当软路由，原理就是别直通网口，然后 pve 默认状态下就是一个交换机，电脑的唯一网口既是网页管理口，也是内部虚拟交换机上的一个 lan 口，

只需要将这个口和光猫（光转电）的 lan 口接在同一个物理交换机的不同口中，就相当于将 pve 内部虚拟交换机和外部物理交换机串联了，也就等于光猫接入了 pve 内部交换机，


那么创建一个 op 虚拟机，同时 pve 为该虚拟机创建两个虚拟网卡，一个在 op 系统中设置为 wan ，一个是 lan ，然后这两个虚拟网口只要网段别一样就不会出现环路。

@BBCCBB 是这样，但 jb 软件右下角能看到项目运行时必要的内存用了多少（不排除是插件实现的），我意思是我分了 64g ，然后实际占用 63g+，平时一个项目给 2g ，实际占用有多有少，当然了宿主机那边肯定看到 2g 用掉的

这么说吧，idea 或者是 jb 家的其他软件，我有次调试生产数据时（一次达到千万条），datagrip 老崩溃，然后我手动设置内存占用直接给到 64g ，然后没崩溃过了，看内存占用情况发现 64g 全吃满。

正经 java 项目开发，16g 都属于不够用的，我司给每个开发配的台式电脑一律 32g 起步。

如果你老板不愿意加内存，又是几十个项目相互依赖启动，那么有一个办法解决，那就是借助私有 maven 仓库。

把那些底层依赖做成 jar 包传上去，然后在新项目的 pom.xml 中指定那堆依赖的 jar 包坐标，这样几十个 jar 包运行起来作为依赖来运行新项目的编译，16g 够用的。

如果 bug 是底层某个依赖出的问题，可以单独修复那个依赖的 bug 然后自动发布到私有 maven 仓库中，然后再调试最终的新项目，所以怎么搞都是够用的，idea 足够好用，坚守 eclipse 可能只有这些原因：

1. 维护的项目老得离谱
2. 组内有大牛专精 eclipse ，不喜欢 idea ，而且有绝对话语权，你们都得迁就他
3. 你们心态上有版权洁癖，不想买正版 jb 全家桶，也不屑用 d 版
4. 你们有的项目用到一些插件只有 eclipse 才有的
5. 你们没有私有 maven 仓库，项目初始化时无法脱离网络而完成

我个人暂时想到这些理由，否则没有理由放着高铁不坐，非得走路从北京到广州

14 楼我发的那个工具是 9 楼的功能强化版本，看 9 楼可以简单理解工作原理，实际我这工具支持 root 和非 root 用户，涉密和非涉密系统

mysql 5.7 系列版本和 mariadb 的数据库我曾写过一个纯 shell 实现的小工具，你只需要往配置文件中按照提示填写必要的参数，然后命令行依次进行：
1. 检查
2. 检查没问题就运行
3. 运行没问题就安装
数据库就全自动备份了（全量），适合于对 linux 命令行操作没经验的产品类人员
目前应用在好些省市的政府服务器上生产验证了的
开源的暂时在 dev 分支，欢迎试用 : -)

https://github.com/mylovesaber/Tools-Share/tree/dev/shell-tool/other/mysql-backup

我不打游戏，给楼主一个参考，我买了罗技 g604 ，觉得好用又买了一个，家里一个公司一个，这鼠标优势：
1. 5 号电池驱动，一颗能用三个月（每天 12 小时以上）
2. 按键多还有 G 键（牺牲一个按键的功能，让剩余所有按键功能数量 x 2 ），写代码时几乎所有常用键盘组合键都放鼠标上了，一个大拇指几乎全搞定
3. 人体工学大趴鼠，保护腕关节
4. 罗技独有的无级滚轮

上面第三点，趴鼠意味着不用在意重量，全程推拉操作，不需要抬手

我在好几年前买过，当初玩 pt 时买的，性价比当初看着是高，但实际体验下来读写速度和 hc550 系列简直没法比，立式硬盘插座上对比，这种降速盘噪音比正经数据中心的 hc550 基本没区别，价格也没啥区别，但读写只有 550 的一半，基本是个残废，而且盘体本身体质就是 hc550 企业规格不达标才降速成这种盘来卖的

@pursuer 其实一般人也不会轻易动系统中的 libc ，主要的冲突点就是国内一群人用 centos7 ，然后遇到比如等保验收或者攻防演练时又不能用老版本软件，新版软件又必须要新版本 glibc ，然后一些 sm 环境禁止用 docker ，就每个软件都得内嵌一个 glibc ，相当得蛋疼，比如 redis ，一个软件编译出来就 5m ，自包含所有自有依赖后，体积将近 400m ，虽然打成 rpm 包只有 35m 左右，这情况刚好跟楼主说的那情况差不多了

@Nich0la5 linux 系统中，内核为系统最底层，在内核之上，有且只有一个程序集合叫 glibc （不考虑其他分支的前提下），剩下能组建出用户可用的 linux 系统的所有程序几乎在运行时都要调用 glibc ，因为所有程序都希望小，依赖细化，即 A 程序依赖于 B 和 C 依赖程序，所以 A 本身不包括 B 和 C 的依赖，只有当你装了 B 和 C 后，A 才被允许安装进系统。结果导致对 glibc 的版本强关联，你可以随便乱升级各种软件的二进制，但你不能随便升级 glibc 二进制，因为如果只升级 glibc ，你系统直接报废，只剩一个内核能运行，所以如果有一个软件不希望缚手缚脚，那么他运行时就需要内置一个 glibc ，间接得，linux 软件包开始推广通用包结构，比如 flatpak （不是说他就内置了 glibc ），deepin 也有了自己的玲珑结构，目的就是要摆脱又臭又长自身又不内嵌的依赖链（树），只要内核允许的最低 glibc 版本低于软件本身依赖，这个软件不能运行，哪怕其他任何一个软件对 glibc 有刚需依赖而 glibc 版本低导致运行不了，都跟自己没一丁点关系，兼容性 max 了

请教下，如果是全新安装的话，登录需要手机号验证码这个现在有什么解决办法吗？

楼主请教下，你这机器只保留系统盘的前提下，空载功耗有多少啊？

我找到的避开的方式，正如我预期的一样，如果我取消变量：
unset \
FFLAGS \
FCLAGS \
CFLAGS \
CXXFLAGS \
LDFLAGS
那么构建完成的 libsystemd.so 就一定不带 libgcc_s 的依赖，但减小其中任意一个或多个变量，结果没法稳定复现，总在三种可能之间乱跳：
- 编译不过
- 不带 libgcc_s 依赖
- 带 libgcc_s 依赖

反而是另外我看着最像问题来源的几个变量居然不处理也不会出问题：
LT_SYS_LIBRARY_PATH \
PKG_CONFIG_PATH \
RPM_LD_FLAGS \
RPM_OPT_FLAGS
@wk333 @codehz 虽然问题可以解决，但我好奇为啥会出现这问题

@wk333 感谢回复，我更新了我的查找结果，请看 6 楼

@codehz
命令 file /usr/lib/rpm/redhat/redhat-annobin-cc1 结果是：
/usr/lib/rpm/redhat/redhat-annobin-cc1: symbolic link to redhat-annobin-select-annobin-built-plugin

命令 ll /usr/lib/rpm/redhat/redhat-annobin-cc1 结果是：
lrwxrwxrwx. 1 root root 42 Oct 4 23:54 /usr/lib/rpm/redhat/redhat-annobin-cc1 -> redhat-annobin-select-annobin-built-plugin

命令 file /usr/lib/rpm/redhat/redhat-annobin-select-annobin-built-plugin 结果是：
/usr/lib/rpm/redhat/redhat-annobin-select-annobin-built-plugin: ASCII text

命令 cat /usr/lib/rpm/redhat/redhat-annobin-select-annobin-built-plugin 结果是：
*cc1_options:
+ %{!-fno-use-annobin:%{!iplugindir*:%:find-plugindir()} -fplugin=annobin}

关于这个文件我找到了这个软件包的构建 git：
https://src.fedoraproject.org/rpms/redhat-rpm-config/tree/rawhide

这里面有和上面 cat 出来的信息完全相同的内容，请过目

ldd 查看的依赖都应该是运行依赖，直接手动执行构建的话，我查看了 lfs 手册，systemd 的运行依赖不可能包含 gcc 的动态库，也就是一楼手动构建完成后 ldd 看到链接的动态库对应是 glibc/libcap/zstd/xz ，而不应该对 gcc 有运行依赖。

我尝试将 spec 文件中的解压缩还有 meson 和 ninja 构建命令都拿到了一个子脚本中，通过在 spec 文件中执行 shell 脚本来构建，结果出来的 libsystemd 动态库依旧有 libgcc_s 的运行依赖


libgcc_s 库绝对路径中的路径/lib64 其实是/usr/lib64 的软链接，我怀疑 rpmbuild 在运行时临时产生了一些环境变量导致，我通过往子脚本中添加 set 和 env 命令抓出来了变量，然后和手动执行命令重定向的变量进行 diff ，发现有很多不同的地方，搜索关键字 lib64 还是能出来不少，明天再一个个对比下看看。。。好诡异。。。