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 还是能出来不少，明天再一个个对比下看看。。。好诡异。。。

@codehz 但 LDFLAGS 应该是链接库用的，这里面选项我查了下好像都不是和使用 libgcc 有什么关联的样子？我是否理解有什么错吗？

@codehz 你意思是手动构建的时候，meson 和 ninja 构建是直接连到了系统中的 libgcc.a ，而 rpm 构建的时候链接到了 libgcc_s.so ？

我能看到和 libgcc_s 有关的库：
find /usr/lib -name libgcc*结果有：
/usr/lib/gcc/aarch64-redhat-linux/13/libgcc.a

find /usr/lib64 -name libgcc*结果有：
/usr/lib64/libgcc_s-13-20230728.so.1
/usr/lib64/libgcc_s.so.1
/usr/lib64/libgccpp.so.1
/usr/lib64/libgccpp.so.1.5.0

ll /usr/lib64/libgcc_s.so.1 结果有：
lrwxrwxrwx. 1 root root 25 Jul 28 08:00 /usr/lib64/libgcc_s.so.1 -> libgcc_s-13-20230728.so.1

现在的问题是，systemd 是 meson 构建，我不知道如何传递 gcc 的选项参数给它。

rpmbuild 启动后会指定这些环境变量，这里面有没有可能导致走的链接 libgcc_s.so ？我知道 libgcc 有关的库是构建 gcc 源码的时候生成的库（之前测试过），但
+ CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
+ export CFLAGS
+ CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
+ export CXXFLAGS
+ FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules '
+ export FFLAGS
+ FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules '
+ export FCFLAGS
+ VALAFLAGS=-g
+ export VALAFLAGS
+ LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes '
+ export LDFLAGS
+ LT_SYS_LIBRARY_PATH=/usr/lib64:
+ export LT_SYS_LIBRARY_PATH
+ CC=gcc
+ export CC
+ CXX=g++
+ export CXX

@air00dd 损坏的话刀锋钛看样子不是的，就是 cpu 电压低了导致网卡无法启动，之前还真没遇到过这毛病，好奇怪。。。而且 win10 相比 win11 调整好电源策略后，cpu 频率比 win11 低 0.1-0.2ghz 不知道什么情况，但看温度又是一样的。。。

@diguoemo 是的，看名字可能是 2 代，据说 3 代才算解决问题，不过我纳闷的是，为啥降压会导致这网卡无法启动，我改回自动电压再开机，网络可用了

@optional 我这英特尔 i7-13700k ，我尝试把电压改回来就恢复，降压居然会在 win 下网卡无法启动。。。而且 win10 下调整电源策略后，相比 win11 频率明显低 0.1-0.22ghz 不知道什么原因

@dxgfalcongbit 怎么说呢？请教下？加压超频坏了就真坏了，降压应该只能算不稳定吧？

@deorth 我把电压改回自动，然后重启进 ubuntu 安装盘，发现网络正常，再重启进 win 也正常了，看样子微星这板子降压超频会导致网卡启动不起来。。。

m1pro,16mbp 我还以为是我个例呢，还想着要不要换一个指纹识别，有时候指纹接触秒开，有时候需要按下去才有用，有时候怎么按都无效，而且没有办法稳定复现

bt/pt 协议下，想下载快，得有做种人，而且不仅要做种人多，他们多数人上传速度也要快，你才能下载得快，这是核心设计理念。

迅雷快是因为他下载有两种途径，目的都是从公网获取了其他人的共享资源，将这些资源归为己有，只分享给开会员的人，而且为所有装了迅雷软件的电脑强制已下载的资源进行做种，占用他们上传带宽。

这样，他们可用的上传来源就有两种人，一种是所有装了迅雷软件的电脑，一种是公网 bt tracker 能连上的人。

然后迅雷用户的下载渠道就有两种：
1. 公网 bt ，你不给钱也能下载，就是下载速度非常慢，这种情况就是迅雷连上公共 bt ，然后通过这些公共 bt tracker 连接到有在上传的人时的传输速度，这种速度理论上和传统 bt 软件下载资源时的速度一样快。
2. 迅雷私有会员渠道，如果不付费直接 0 速度，那就是这资源只在安装了迅雷软件且下载过该资源的迅雷用户电脑上有（无论是否有付费），因为迅雷强制这些用户电脑做种，所以但凡有资源被迅雷完整下载过，且那用户没有关掉迅雷进程且资源没被删除的话，其他迅雷用户只要开了会员就能下

所以吸血雷的名号由此而来，网上有很多科普介绍，其实都不靠谱，因为原理对不上